About ORM source models

Show me an example

Use the ORM Source Model template to create Object Role Modeling (ORM) source models.

Click to show or hide information. What is ORM?

ORM is a high-level, conceptual approach to data modeling that describes the application domain using intuitive symbols and natural language facts that both users and designers can understand. ORM provides an extensive set of constraints to capture business rules, and ORM lets you incorporate sample populations to verify your design.

Click to show or hide information. How are ORM source models mapped to a physical database?

ORM source models cannot be mapped directly to physical databases. You must first add your ORM source model to a project and then build a logical model, which you can then use to generate or update a physical database.

When you add an ORM source model to a project and then build a logical model:

  • A new project document is created that contains your model.
  • The ORM elements are translated into the equivalent logical objects in the project's model.
  • The project document opens with the Tables window displayed.

After you build a logical model, you can:

  • Generate a database schema.
  • Make changes to the logical model and have those changes written back to your ORM source model.

Notes

  • You can build your model in a new project or in an existing one.
  • Before building a project, check your source model for errors by clicking Model Error Check on the Database menu. When you build a project, Visio checks your source model for other types of errors.
  • After you build the project, you can drag tables and relationships onto the drawing page and refine the model.

For information about Object Role Modeling, see Conceptual Schema and Relational Database Design, 2nd edition, by Terry Halpin (WytLytPub, Bellevue WA, USA, 1999), and visit http://www.orm.net/, the official Web site for conceptual data modeling.

Create an ORM source model


Create an ORM source model

Show me an example

  1. To start your ORM source model, do one of the following:

Click to show or hide information. Create a new model from scratch.

  1. On the File menu, point to New, point to Database, and then click ORM Source Model.
  2. On the Database menu, point to Options, and then click Document. In the ORM Document Options dialog box, choose options for your ORM model.
  3. Create facts by doing either of the following:
  • Connecting object types and predicates with role connectors
  • Defining facts in the Fact Editor
  4. Check for entity types that should be combined, and note any arithmetic derivations.
  5. Add uniqueness constraints, add mandatory constraints, and check for logical derivations.
  6. Add any value, set comparison, or subtyping constraints.
  7. Add other constraints.

Click to show or hide information. Use a reverse engineered model as a starting point.

  1. On the File menu, point to New, point to Database, and then click ORM Source Model.
  2. On the Database menu, click Reverse Engineer.
  3. On the first screen of the Reverse Engineer Wizard, do the following:
  • Select the Microsoft Visio database driver for your database management system (DBMS). If you have not already associated the Microsoft Visio database driver with a particular 32-bit ODBC data source, do so now.
  • Select the data source of the database you're reverse engineering. If you have not already created a data source for the existing database, do so now.

Note When you create a new source, its name is added to the Data Sources list.

  • When you are satisfied with your settings, click Next.
  4. Follow the instructions in any driver-specific dialog boxes.

For example, in the Connect Data Source dialog box, type a user name and password, and then click OK.

  5. Select the check boxes for the type of information you want to extract, and then click Next.
  6. Select the check boxes for the tables (and views, if any) that you want to extract, or click Select All to extract them all, and then click Next.
  7. If you selected the Stored Procedures check box in step 5, select the procedures that you want to extract, or click Select All to extract them all, and then click Next.
  8. Review your selections to verify that you are extracting the information you want, and then click Finish.

The wizard extracts the selected information and displays notes about the extraction process in the Output window.

  9. Create a diagram of your model by dragging facts from the Business Rules window onto the drawing page.

After dragging object types from the Business Rules window to the diagram, you can right-click the object type and click Show Relationships to instantiate the facts it is involved in.

Click to show or hide information. Import and refine an existing model.

  1. On the File menu, point to New, point to Database, and then click ORM Source Model.
  2. On the Database menu, point to Import/Export, and then click Import VisioModeler .IMO file.
  3. Type the path and file name for the model you want to import, or click the Browse button to locate the model file, and then click Open.
  4. Click OK in the Import dialog box.

Visio imports the file and displays its progress in the Output window.

  5. In the Business Rules window, select the facts you want to see, and then drag them onto the drawing page.
  2. Once you start an ORM source model, the real work of refining it begins. For example, you can edit the facts and constraints in your model, and add new ones. To refine your ORM source model, follow the same steps used to create an ORM source model from scratch (outlined above).
  3. When you're satisfied with your ORM source model, you can add it to a new or existing project.

Click to show or hide information. Create a new project

  1. On the File menu, point to New, point to Database, and then click Database Model Diagram.
  2. On the Database menu, point to View, and then click Project to open the Project window.
  3. On the File menu, click Save, type a name for the project, and then click the Save button.

Click to show or hide information. Add a model to a project

  1. Open an existing project file, or create a new one.
  2. Do one of the following:
  • On the Database menu, point to Project, and then click Add Existing Document.
  • In the Project window, right-click Project, and then choose Add Existing Document.
  3. In the Add Document to Project dialog box, select the name of the file you want to add.

Note You can add ER or ORM source model files (.vsd files) or other documents of any file type that you want to associate with the project.

  4. Click Open.
  4. After you add your model to a project, you can do the following:
  • Refine the logical model in the project and migrate any changes back to your source model.
  • Use the Generate Wizard to create a database schema.

You can generate a new database directly if your DBMS supports the direct creation of a new database. If your DBMS does not support direct creation, you must use a DDL script to create the physical database.

Click to show or hide information. Tip

Before using the Generate Wizard, you should build your project so that it incorporates the most recent changes in the ORM source model.

  • If you reverse engineered an existing database, you can use the Refresh Model Wizard to update your model based on changes to the physical database. In addition, you can use the Update Database Wizard to update the physical database based on changes you've made in your model.

Click to show or hide information. Tip

Before using the Generate Wizard, you should build your project so that it incorporates the most recent changes in the ORM source model.

  5. Use the New Report Wizard any time in the process to generate reports that document your design or communicate information about the database to a client. To start the wizard, on the Database menu, click Report.


About role connectors and fact types

After you draw the object types and predicates that make up a fact, you can connect them using role connectors.

A role connector is a graphical representation of the relationship between an object type and its role in a predicate. In a fact type, role connectors appear as solid lines.

Each role in a predicate can be connected to only one object type, and each object type must be connected to at least one role.

Click to show or hide information. Role connectors illustrated

Role connectors (A) on the Predicate shape

Predicate shape with role connector and role box selected.

Predicate shape with role connector and role box selected

Drag a role connector on the Predicate shape to glue it to an Object Type shape.

Drag a role connector on the Predicate shape to glue it to an Object Type shape.

Click to show or hide information. Tip

The quickest way to add a fact type to an ORM diagram is to use the Fact Editor, which creates a fact type that you can customize.


Connect an object type with a role (ORM)

  1. Open the ORM Source Model file that represents your model.
  2. Drag an Object Type shape onto the drawing page if you have not already done so.
  3. Drag a Predicate shape onto the drawing page if you have not already done so.
  4. Select the role connector on the Predicate shape that you want to connect to the Object Type shape, and then drag the control handle [image] to a connection point [image] on the Object Type shape. When the selection handle turns red, release the mouse button.


About the Fact Editor

How the Fact Editor works

Click to show or hide information. Create and edit facts

You can create new facts and edit existing facts in an ORM source model using the Fact Editor.

In the Fact Editor, you can define, edit, and add constraints to fact types and then let the Fact Editor automatically draw the correct symbols and constraints on the diagram.

The Fact Editor also ensures that your fact types are correct by checking the syntax of a fact type and its components as you create it.

Click to show or hide information. Fact Editor tabs

In the Fact Editor, you start at the first tab (Fact) and then work through each tab, from left to right, to create a new fact type.

The Fact Editor checks the syntax of your fact type as you create it. If you have not entered sufficient information to define a complete fact type, the Fact Editor prevents you from opening other tabs. After you enter sufficient information about the fact type, you can move back and forth among the tabs as you need.

If you make an error, the Fact Editor notifies you as you work.

Fact types

Click to show or hide information. About

A fact type defines the set of all possible object types that play the associated roles in a given application domain. A fact type must contain at least one object type and at least one role.

Click to show or hide information. Choose how to enter a fact type

On the Fact tab, you can choose how to enter a fact type:

  • Freeform style displays a single box in which you can simply type. This option offers you both the greatest flexibility and the ability to enter advanced forms of fact types, such as fact types with arity greater than four and predicates with prefixes or suffixes.
  • Guided style displays boxes for object names and predicate text, making it easy to enter the correct syntax for the fact type.

Object types

Click to show or hide information. Classify new object types

In the Fact Editor, use the Object tab to classify the new object types in the facts that you are creating or editing. Select the name of a new object type in the list, and then select options.

On the Object tab, the Fact Editor lists the names of the object types you have entered.

You need to classify only new object types. If you enter the name of an existing object type in the current ORM source model, the Fact Editor automatically fills in the classification information about that object type. You can edit the data if you want, and the Fact Editor updates the information for all instances of that object type in the current source model.

Predicates

Click to show or hide information. Inverse predicate text

Every predicate that has two or more roles can be read in reverse (from right to left). Use a forward slash (/) between the forward reading and the inverse reading of the predicate.

The following example shows the forward and inverse reading of several fact types:

Employee works on Project/Project has Employee

[store] is located in [city]/[city] is location of [store]

Manager heads Department/Department is headed by Manager

Although entering inverse predicate text is not required, it often clarifies the constraints you must apply.

Notes

  • To make entering the inverse reading of a binary fact type mandatory, on the Database menu, point to Options, and then click Modeling. Click the Fact Editor tab, choose Miscellaneous Preferences from the Category list, check Inverse required on binary facts, and then click OK.
  • For binary fact types, when you press the "/" key, the Fact Editor automatically begins the reverse reading of the fact. All you have to do is type the inverse predicate text between the object type names.

Click to show or hide information. Prefixes and suffixes with predicate text

To make it easier to express and clarify business facts, the Fact Editor allows you to add prefixes and suffixes to predicate text when you are using the freeform input style. Prefix and suffix text must be lowercase.

The following example shows fact types with prefix and suffix words:

qualified Technician(Code) works on Project(Name)

Student(ID) works as Intern(Number) in the summer

Click to show or hide information. Verbalization of predicates with auxiliary words

When the predicate of a fact type contains an auxiliary word, you can enter a hyphen (-) after the word in the Fact Editor to bind the word to the following object term when constraints are verbalized. The following table shows how using a hyphen can clarify the verbalization of a constraint.

Fact type | Constraint Verbalization
Customer has primary Phone (without hyphen) | each Customer has primary at most one Phone
Customer has primary-Phone (with hyphen) | each Customer has at most one primary Phone

Example data

Click to show or hide information. About example data

Use the Examples tab to enter example data for a fact type. Each row represents an instance of data for each object type that plays a role in the fact type.

The Fact Editor uses the example data you enter to determine the uniqueness constraints for your fact type and notifies you if it detects any conflicts between the example data and the constraints.

Entering example data is the most effective way to verify that a fact type is complete and accurate.

Click to show or hide information. Tips for entering example data

  • Enter significant examples. The example data that you enter should represent all possible combinations of data.
  • Do not repeat rows of data. An elementary fact type determines the combinations of data allowed at each role position.
  • Do not include null values. The example data must include an actual value for each cell in the population table.


About input styles in the Fact Editor

When you use the Guided input style, the Fact Editor helps you enter fact types by providing prompts and boxes based on the arity of the fact you are creating.

When you use the Freeform input style, the Fact Editor displays a single box in which you can simply type. This option offers you both the greatest flexibility and the ability to enter advanced forms of fact types, such as fact types with arity greater than four and predicates with prefixes or suffixes.

To enter a fact type in freeform style, first type the forward reading of the fact. All text other than the object names is called the predicate text. Predicate text must be lowercase.

Click to show or hide information. Object type syntax

If you select Capitalized from the Freeform Input Style list on the Fact tab, use an initial capital letter for the name of an object type. For example, the following fact type contains two object types, person and name:

Person has Name

For the rest of an object type name, you can use any combination of characters and an underscore. Do not use a space within an object type name; use an underscore instead.

If you select [bracketed] from the Freeform Input Style list on the Fact tab, use square brackets [ ] around a name to indicate an object type in a fact. For example, the following fact type contains two object types, customer and order:

[customer] places [order]

To include the following special characters or a space character in an object type name or in predicate text, type a reverse slash (\) and then the character:

( ) [ ] / \ ?

For example, the following fact type creates an object named Account Type that contains an internal space:

Person has Account\ Type

Use singular nouns for object type names. For example, use Employee, not Employees.

Click to show or hide information. Classifying object types

Classify an object type as an entity, value, or external object by doing the following:

  • Enter text in parentheses after the name of an object. Use any combination of characters including an underscore or a space.
  • For the bracketed input style, put the reference mode inside the parentheses.
  • To indicate a value object type, use empty parentheses.
  • To indicate an external object type, use a question mark (?).
  • An object name without any parentheses is considered an entity.

For example:

Employee(empNr) has Surname()

Click to show or hide information. Indicating the reference mode for entity object types

Indicate the reference mode for an entity object type by doing the following:

  • Enter text inside parentheses. By default, the Fact Editor classifies the reference type of a reference mode that consists of text as Identification.
  • To indicate a formatted reference mode, use single or double quotation marks.
  • To indicate a measurement reference mode, use a pound sign (#).

Click to show or hide information. Predicate text syntax

Use prefixes and suffixes.

To include the following special characters or a space character in an object type name or in predicate text, type a reverse slash (\) and then the character:

( ) [ ] / \ ?

For example, the following fact type creates an object named Account Type that contains an internal space:

Person has Account\ Type

Click to show or hide information. Improving verbalization

Use a hyphen to improve verbalization.

Fact type | Verbalization
Customer has primary Phone (without hyphen) | each Customer has primary at most one Phone
Customer has primary-Phone (with hyphen) | each Customer has at most one primary Phone

Click to show or hide information. Example fact types

The following are valid fact types:

Employee works full time

SalesRep is assigned to Customer

[clerk] has [skill_rating]

[Technician] uses [Notebook] on [Project]

Supplier provides Discount

Employee(empNr) works for /employs Department(code)


Enter a new fact (ORM)

  1. On the Database menu, point to View, and then click Fact Editor.
  2. On the Fact tab, under Input style, click one of the following input styles:
  • Freeform displays a single box in which you can simply type.
  • Guided displays separate boxes for object name and predicate text.
  3. Under Input style, do one of the following:
  • If you clicked Freeform, choose the object type delimiter you want to use: [bracketed] or Capitalized.
  • If you clicked Guided, choose the arity of the fact you want to create: Unary, Binary, Ternary, or Quaternary.
  4. Do one of the following:
  • If you clicked Freeform, under Enter freeform fact, type the fact type.
  • If you clicked Guided, in the Object Name box, type the name, and in Relationship box, type the role.

Press TAB or SHIFT+TAB to move from one box to another.

  5. Click the Object tab, and then classify newly created object types.
  6. Click the Examples tab, and then enter example data.
  7. Click the Constraints tab, and then add a constraint.
  8. Do one of the following:
  • Click OK to create the fact type and close the Fact Editor.
  • Click Apply to create the fact type and continue creating another fact type.
  9. After you close the Fact Editor, you can drag one or more fact types from the Business Rules window onto the drawing page. The symbols are automatically drawn for you.


About the Business Rules window

The Business Rules window provides a quick way to enter and edit fact types in your conceptual model.

As you enter business rules, you can drag them onto the drawing page. The drawing page and the Business Rules window are both views of the same model.

Click to show or hide information. All Folders pane

Use this list to organize all the facts in your model, which are always stored in the Entire Contents folder. You can create new folders and copy facts into them to organize the contents of your model.

Click to show or hide information. Fact Types tab

Click this tab to create and edit the fact types in your model. To add a new fact type or edit an existing one, double-click the fact type to open the Fact Editor, or just begin typing to add a new fact type or overwrite an existing one.

Click to show or hide information. Object Types tab

The Objects Types tab lists all the object types that play roles in the currently selected folder, or if the currently selected folder is Entire Contents, it lists all the object types in your model.

Click this tab to create and edit the object types in your model. Each column represents a property of the object type: its display name, data type, kind, and reference mode. For some columns, you can quickly set properties by clicking a cell to display a drop-down list of relevant options.

Object types are sorted first by kind (entity, value, unknown) and then by name. As you add object types, the list is not automatically sorted. To resort object types, right-click an object type and click Refresh.

Click to show or hide information. Physical Data Type column

Specifies the portable or physical data type. Click a cell in this column to display a drop-down list of all the native data types associated with the default database driver, as well as the existing user-defined types in the model.

To enter a new data type, you can type directly into the data type cell. For example, if the native data type is "CHAR" with a length of 25, you can type "CHAR(25)" directly into the data type cell and press ENTER. If the native data type is "DECIMAL" with a precision of 12 and a scale of 2, you can type "DECIMAL(12,2)" and press ENTER.

To modify an existing data type, you can press F2 or double-click the data type cell.

Click to show or hide information. Kind column

Shows whether the object type is Entity, Value, or External.

Click to show or hide information. RefMode column

Specifies the reference mode—the manner in which a value refers to an entity. Applies only to entity types.


Organize facts in the Business Rules window (ORM)

  1. If the Business Rules window isn't already open, on the Database menu, point to View, and then click Business Rules.
  2. Create a new folder.

Click to show or hide information. How?

Under All Folders, do one of the following:

  • To create a folder at the top level, right-click the document name at the top of the tree, and then click New Folder.
  • To create a subfolder within another folder, right-click the existing folder and then click New Folder.

To name the new folder, right-click it, click Rename, type the name, and then press ENTER.

  3. Add facts to a folder.

Click to show or hide information. How?

Select the Entire Contents folder. On the Fact Types tab, select one or more fact types in the Fact Types pane and drag the selected fact types to the desired folder. You may also right-click the selected fact types, click Copy, right-click the desired folder, and then click Paste.

Notes

  • When you create a folder and add fact types to it, you are actually creating shortcuts (or references) to the fact types in the Entire Contents folder. The actual fact types are always stored in the Entire Contents folder.
  • Any object types in a user-defined folder are derived from the fact types in the folder. You cannot directly add object types to a user-defined folder. You can only add object types to the Entire Contents folder.
  4. Move a folder.

Click to show or hide information. How?

Do one of the following:

  • Drag the folder to the new position.
  • Right-click a folder, and then click Cut. Right-click the desired root (or parent) folder, and then click Paste.

Note You cannot move the Entire Contents folder.


About object types

An object type represents a type of real-world object or concept (for example, Person or Job).

An object type:

  • Appears as a noun in English.
  • Begins with an uppercase letter.
  • Must have a unique definition.
  • May be defined only once in the scope of a data model.

You can create two kinds of object types:

Click to show or hide information. Entity object types

An entity object type is an object type whose domain consists of real-world things rather than character strings or numbers. For example, in a retail model, Customer is an entity object type.

In an ORM diagram, an entity object type:

  • Appears as a solid ellipse.
  • Displays its reference mode in parentheses under the name of the object type.

Click to show or hide information. Value object types

A value object type is an object type whose domain consists of numbers or character strings. A value object type generally is used to describe an entity object type. For example, the entity object type, Customer, might be identified by using the value object type, CustomerNumber.

In an ORM diagram, a value object type:

  • Appears as a dashed ellipse.
  • Displays a plus sign (+) next to the name in the ellipse if you define a value object type's data type as numeric and if you also choose to allow numeric operations on it.
  • Cannot have a reference mode.

You can use object types that you create in one model in another model by declaring the object type as external.

Click to show or hide information. External object types

An external object type is an object type that has already been defined in a model or in another model document in a project. To use an object type in more than one model document in the same project file, you must first define the object type in one of the source model documents, and then you must define that particular object as external in the other source model documents.

In an ORM diagram, an external object type:

  • Appears as an ellipse with a shaded background.
  • Cannot have a reference mode (except in the source model in which it is defined).

For example, if the Address object type is defined in the Reference submodel of a project, you can also use it in the Employee submodel if you define it as external.

Click to show or hide information. Object types illustrated

Object type examples.

A Entity object type

B Value object type

C External object type


Draw an object type (ORM)

  1. Open the ORM Source Model file that represents your model.
  2. From the ORM Source stencil, drag an Object Type shape onto the drawing page.
  3. In the Database Properties window, set object type properties.


About object type properties

You set the properties of an object type to capture information about an object type's definition, identity, behavior, and nature in your application domain.

Click to show or hide information. Object type definition

An object type's definition describes its basic properties, such as name and kind of object type. Each different object type in a model must have a unique definition and may be defined only once in the scope of a data model.

Object type names:

  • Can contain any combination of characters.
  • Are not case sensitive.
  • Can contain an internal space.

Notes

  • Give the object types in your conceptual model clear names that are unique and easy to understand.
  • Distinguish two distinct object types that have the same name by setting the Name Space property.

Click to show or hide information. Object type verbalization

You can instruct the Verbalizer to use "his/her" in place of "its" in the verbalization.

Click to show or hide information. Reference modes for entity object types

For any entity object type, you can specify a reference mode, which is a word, number, or abbreviation used to identify a unique instance of an object type.

For example, in the following fact, the entity object type (Employee) is uniquely identified by a reference mode (IDNumber) that has a unique value (A3708).

Employee with the IDNumber "A3708" has LastName "Jones"

Notes

  • In the diagram, the reference mode is placed in parentheses beneath the name of an entity object type.
  • You can specify the type of reference mode to make verbalization of the fact easier to understand.
  • A reference mode is used only for entity object types. Value object types and external object types cannot have a reference mode.

Click to show or hide information. Data types for object types

In a true conceptual model, data types are irrelevant; however, in the practical world, models are typically designed with a physical database in mind.

In the ORM solution, you can specify:

  • User-defined data types.
  • Portable data types.
  • Composite (SQL:1999) types.

By default, an object type's data type is set as text. You can define an object type's data type when you refine your ORM model, or you can define it later when you refine the mapped logical model in the project.

Click to show or hide information. Object types with a limited range or set of values

You can limit the values of an object type to a set of possible values, called a value constraint.

Value constraints can be either of the following:

  • A range of values
  • A list of values

For example, you might limit Gender(code) to the code values M and F, or you might limit SkillRating(nr) to values between 250 and 450.

Note When you define a value constraint on an entity object type, you are actually specifying the set of allowable values on the data type of the underlying identification scheme.

Click to show or hide information. Object types reused on one or more pages

You can reuse object types that you have already defined on one or more pages in the same ORM source model document by doing either of the following:

  • Dragging them from the Object Types tab of the Business Rules window.
  • Dragging them from the Object Types window.

Doing so helps ensure the accuracy of your database design.

Click to show or hide information. Enhanced object types

You can extend the basic properties of an object type—name, kind, and data type—to define more enhanced object types, such as subtypes, supertypes, independent entities, composite object types, and nested object types.


Set object type properties (ORM)

  1. Open the ORM Source Model file that represents your model.
  2. Double-click the object type shape whose properties you want to define to display the Database Properties window.
  3. In the Database Properties window, in the Categories list, click the category that contains the information you want to edit, and make your changes.

The ORM source model is updated automatically.


Define object types in the Business Rules window (ORM)

  1. On the Database menu, point to View, and then click Business Rules to open the Business Rules window.
  2. Click the Object Types tab.
  3. Click in the Object Types column, type the name of an object type, and then press the TAB key.
  4. In the Data Type column, choose an option from the list or type the data type directly (along with its parameters), and then press the TAB key.

To enter a new data type, you can type directly into the data type cell. For example, if the native data type is "CHAR" with a length of 25, you can type "CHAR(25)" directly into the data type cell and press ENTER. If the native data type is "DECIMAL" with a precision of 12 and a scale of 2, you can type "DECIMAL(12,2)" and press ENTER.

To modify an existing data type, you can press F2 or double-click the data type cell.

  5. In the Kind column, choose an option from the list (Entity, Value, or External), and then press the TAB key.
  6. In the RefMode column, type the reference mode name.
  7. Repeat steps 3 to 6 for as many object types as you want.

Note To switch between portable and physical data types, right-click the Data Type column name and then choose Show Portable Data Type or Show Physical Data Type.


Reuse an object type (ORM)

  1. Open the ORM Source Model file that represents your model.
  2. Navigate to the page where you want the new instance of the object type to appear.
  3. On the Database menu, point to View, and then click Object Types.
  4. In the Object Types window, click the name of the object type that you want to reuse.
  5. Drag it to a vacant area on the drawing page where you want the object type to appear.

The object type is added to the diagram.

Click to show or hide information. Tip

You can also drag the object type you want to reuse from the Object Types tab of the Business Rules window.


Delete an object type (ORM)

  1. On the drawing page, select the object type you want to delete, and then press the DELETE key.
  2. In the Delete object dialog box, do one of the following:
  • If you want to remove the object type from the model and from the Object Types window, click Yes.
  • If you want to remove the object type from the drawing page, but not from the model or the Object Types window, click No.

Click to show or hide information. Tip

If the Delete object dialog box does not appear when you delete an object from the diagram, you can change this setting. On the Database menu, point to Options, and then click Modeling. In the Database Model Preferences dialog box, on the ORM Diagram tab, click Ask user what to do.


About predicates

A predicate is the part of a fact that describes the roles played by object types. Each predicate is divided into roles or role positions.

In an ORM diagram, a predicate appears as a sequence of one or more role boxes. The predicate text is a sentence, but with the object terms removed. You can use an ellipsis (…) to indicate a placeholder for an object term. If you don't use ellipses, unary predicates assume the object goes first (for example, "smokes" is the same as "… smokes") and binary predicates assume the objects are at either end (for example, "works for" is the same as "… works for …"). You must use ellipses if the object terms go in other positions, or if the predicate is ternary or longer (for example, "in … … was born," "… was sold by … during …").

You can read a predicate from left to right. This reading of the predicate is called the forward text of a predicate.

Every predicate that has two or more roles can also be read in reverse (from right to left). This reverse reading is called the inverse text of a predicate, which is indicated in ORM by a forward slash (/) character (for example, "Person works for/employs Company"). Entering the inverse text of a predicate is optional, but highly recommend for binary facts.

Notes

  • Unary facts do not have inverse predicate text because they have only one role.
  • Entering both the forward and inverse predicate text on binary facts clarifies the relationships between the object types.
  • Facts of ternary and higher arity may have multiple readings, one starting at each role.

Click to show or hide information. Predicate shape

You can quickly add a role to your model by using the Predicate shape from the ORM Source stencil.

After you create a predicate, you can:

  • Define its properties, including arity, examples, and constraints.
  • Connect the predicate to an object type to create a fact type.

Click to show or hide information. Arity

The role count of a predicate determines its arity. A predicate can include up to nine roles. You define arity when you set a predicate's properties.

Arity of fact | Number of roles | Example
Unary | 1 | Car is registered
Binary | 2 | Customer places/is placed by Order
Ternary | 3 | Technician uses Notebook on Project
Quaternary | 4 | Course is assigned to Section in Semester of Year
Other | 5...9 | —

Click to show or hide information. Name space to distinguish identical predicates

Each predicate must have a unique definition in the model. The definition of a predicate includes the object types attached to it, as well as its properties, such as predicate text.

If one predicate has the same definition as another, you can use the Name Space property to distinguish between the two predicates.

Click to show or hide information. Example data for predicates to check uniqueness

You can enter example data for a predicate to automatically check the uniqueness constraints of a fact.

Entering example data is optional, but offers several benefits:

  • When you validate your model, the uniqueness constraints are compared to your example data.
  • Visio can suggest the correct uniqueness constraints based on your example data.
  • You can automatically apply the suggested uniqueness constraint to your model.

Click to show or hide information. Predicate illustrated

This example shows the parts of a predicate as they appear on the drawing page.

A Role connectors

B Role boxes

C Forward text

D Inverse text


Create a predicate (ORM)

  1. Open the ORM Source Model file that represents your model.
  2. From the ORM Source stencil, drag the Predicate shape onto the drawing page.
  3. Set the predicate's properties.

Click to show or hide information. How?

  1. Double-click the predicate whose properties you want to define to display the Database Properties window.
  2. In the Database Properties window, in the Categories list, click the category that contains the information you want to edit, and make your changes.

The ORM source model is updated automatically.

  4. Define the predicate's arity.

Click to show or hide information. How?

  1. Double-click the predicate whose arity you want to define, and then, in the Database Properties window, in the Categories list, click Definition.
  2. From the Arity list, select an arity value.

The ORM source model is updated automatically.

  5. If desired, enter example data for the predicate.

Click to show or hide information. How?

  1. Double-click the predicate to which you want to add example data, and then, in the Database Properties window, in the Categories list, click Examples.
  2. Type the example data.

The number of columns matches the arity of the predicate you are defining or editing. Press the Tab key to move forward one column, and press Shift+Tab to move back one column.

The ORM source model is updated automatically.


Delete a predicate (ORM)

  1. Open the ORM Source Model file that represents your model.
  2. Select the predicate you want to delete, and then press the DELETE key.
  3. In the Delete object dialog box, do one of the following:
  • If you want to remove the object type from the model and from the Object Types window, click Yes.
  • If you want to remove the object type from the drawing page, but not from the model or the Object Types window, click No.

Note If the Delete object dialog box does not appear when you delete an object from the diagram, you can change this setting. On the Database menu, point to Options, and then click Modeling. In the Database Model Preferences dialog box, on the ORM Diagram tab, click Ask user what to do.


About constraints in ORM

After enter fact types—using the Business Rules window or the Fact Editor—you can apply constraints. Use constraints to capture additional meaning within and between the fact types in your conceptual model.

You can think of constraints as rules that you apply to fact types to restrict the data that is allowed in the database. After you apply constraints, you can analyze and check the validity of the constraints using example data.

Click to show or hide information. Internal and external constraints

Constraints are either internal or external.

Constraint type | Used for
Internal | Only a single predicate.
External | Two or more predicates.

Click to show or hide information. Constraints illustrated

A An internal uniqueness constraint indicates that each author has at most one last name.

B A mandatory constraint indicates that every author must have a last name.


Constraint types (ORM)

Uniqueness constraints

Click to show or hide information. About uniqueness constraints

Uniqueness constraints are the most commonly applied constraints in a conceptual model.

Use a uniqueness constraint to indicate that a role or combination of roles cannot contain duplicate values.

Uniqueness constraint examples.

A Internal uniqueness constraint.

B External uniqueness constraint.

Click to show or hide information. Internal uniqueness

You can apply an internal uniqueness constraint (also known as an "intrapredicate uniqueness constraint") to one or more roles in a given fact type when you want to specify that every instance of data within the role or combination of roles must be unique.

Internal uniqueness constaint example.

This internal uniqueness constraint and the sample data show that each Person has at most one LastName and that many Persons can have the same LastName. Each instance of the object type Person is unique in the population of this fact type.

An internal uniqueness constraint can also span all roles in a fact type, which means that each instance of the entire fact type is unique.

You can apply more than one uniqueness constraint to any binary, ternary, quaternary, or n-ary fact. Every uniqueness constraint must span at least n-1 roles, where n is the number of roles in the predicate.

Click to show or hide information. External uniqueness

You can apply an external uniqueness constraint (also known as an "interpredicate uniqueness constraint") to two or more roles in different fact types when the fact types share the same object type. When you map your conceptual model to a logical model, a unique index is created on the roles spanned by an external uniqueness constraint.

Use an external uniqueness constraint when you want to identify an alternate method for uniquely identifying an object type.

For instance, suppose your application tracks towns in a state, including their longitude and latitude. Suppose each town has a unique name. Towns can have the same longitude or latitude, but not both.

With this information you know that you can uniquely identify a town is by its longitude and latitude. To specify this in an ORM source model, you apply an external uniqueness constraint to the roles played by longitude and latitude:

External uniqueness constraint example.

Click to show or hide information. Primary uniqueness

A primary uniqueness constraint (also known as a "primary reference constraint") is a uniqueness constraint that is designated as the primary reference when there are two or more uniqueness constraints that identify an object type. For example, a State can be identified by its unique two-letter abbreviation or by its name. You can designate the two-letter abbreviation as the primary reference.

Use a primary uniqueness constraint to indicate that an object type is primarily identified by the role(s) spanned by that uniqueness constraint.

Primary uniqueness constraint examples.

A Primary internal uniqueness constraint.

B Primary external uniqueness constraint.

Mandatory constraints

Click to show or hide information. Simple mandatory

To show that every instance of an object type's population must play a particular role, apply a mandatory constraint to that role.

Simple mandatory constraint examples.

A Internal simple mandatory constraint.

B External simple mandatory constraint.

For instance, to enforce the rule that each Country must have a CountryName, you would apply a mandatory constraint, for example:

Mandatory constraint example.

Click to show or hide information. Disjunctive mandatory (inclusive or)

If two or more roles are connected to the same mandatory role dot, this means the disjunction of the roles is mandatory. In other words, each instance in the object type's population must play at least one of the roles in the constraint.

For instance, to enforce the rule that each Employee must have a Social Security Number or a driver's license (or both), you would apply a disjunctive mandatory constraint, for example:

Disjunctive mandatory constraint example.

Ring constraints

Click to show or hide information. About ring constraints

You can apply a ring constraint to a pair of roles connected to the same object type.

Note You can also apply a ring constraint to a pair of roles connected to different object types if the object types are in the same subtype graph.

Click to show or hide information. Acyclic ring

With an acyclic ring constraint, there are no cycles in the relation. For example, if you have data combinations (A, B) and (B, C), you cannot have data combination (C, A).

Acyclic ring constraint example.

Acyclic ring constraint.

Click to show or hide information. Asymmetric ring

In an asymmetric ring constraint, if you have a data combination (A, B), you cannot have data combination (B, A).

Asymmetric ring constraint example.

Asymmetric ring constraint.

An asymmetric constraint implies the existence of an irreflexive constraint. For example, Tom cannot be the older brother of himself (A, A).

Click to show or hide information. Antisymmetric ring

In an antisymmetric ring constraint, if you have data combination (A, B), you can have data combination (A, A), but you cannot have data combination (B, A).

Antisymmetric ring constraint example.

Antisymmetric ring constraint.

For instance, an antisymmetric constraint can express this fact type:

Person claims Person for tax.

Notes

  • An antisymmetric ring constraint is an asymmetric constraint without the implied irreflexive constraint.
  • An antisymmetric ring constraint allows symmetric data only when it is the self.

Click to show or hide information. Intransitive ring

With an intransitive ring constraint, if you have data combinations (A, B) and (B, C), you cannot have data combination (A, C).

Intransitive ring constraint example.

Intransitive ring constraint.

Click to show or hide information. Irreflexive ring

An irreflexive ring constraint prohibits an object instance from playing two roles in the same relationship instance—no instance can bear the relationship to itself. For instance, people cannot be their own parents.

Irreflexive ring constraint example.

Irreflexive ring constraint.

Click to show or hide information. Symmetric ring

With a symmetric ring constraint, if you have data combination (A, B), you must have data combination (B, A). For instance, if A is a sibling of B, B must also be a sibling of A.

Symmetric ring constraint example.

Symmetric ring constraint.

Set-comparison constraints

Click to show or hide information. About set-comparison constraints

Use a set-comparison constraint to restrict the way the population of one role sequence relates to the population of another role sequence.

For instance, a movie cannot be exported to the same country in which it is made, and a person can have a parking permit or a bus allowance, but not both.

Click to show or hide information. Subset

A subset constraint indicates that the population of the first role sequence is a subset of the population of the second role sequence.

Apply a subset constraint when two role sequences are played by the same object type and all the roles are optional. The role sequences can be in the same fact type or in different fact types.

Subset constraint examples.

A Internal subset constraint.

B External subset constraint.

For instance, if an application tracks the start date and the end date of projects, we can express these facts:

Project(nr) started on Date(mdy)

Project(nr) ended on Date(mdy)

The business rule is: A project cannot have an end date unless it also has a start date. Create a subset relationship between the roles played by the object type, Project, in both facts.

Click to show or hide information. Equality

An equality constraint joins two roles into a conditional relation. The population of the first role sequence must be equal to the population of the other role sequence involved in the constraint, and vice versa.

Use an equality constraint when two or more role sequences are played by the same object type and all the roles are optional. The roles can be in the same fact type or in different fact types.

Equality constraint examples.

A Internal equality constraint.

B External equality constraint.

For instance, you can write the following facts about a company that has an optional van pool program for employees who want to share a ride:

Employee(id) is assigned VanPool(number)

Employee(id) is assigned FrequentRider(status)

To express the business rule that the FrequentRider status of an employee is recorded if and only if a VanPool number for an employee is also recorded, use an equality constraint between the roles played by Employee.

Click to show or hide information. Exclusion

An exclusion constraint excludes an instance of one non-mandatory role from being an instance of another non-mandatory role. That is, the population of the first role sequence cannot occur in the population of the other role sequence.

Use an exclusion constraint when two or more role sequences are played by the same object types. The role sequences can be in the same fact type or different fact types.

Exclusion constraint examples.

A Internal exclusion constraint.

B External exclusion constraint.

For instance, you can express the following facts about a company that assigns parking to employees:

Employee(id) is assigned ParkingSpace(nr)

Employee(id) received ParkingAllowance(USD)

The business rule is: An employee can receive a parking allowance or be assigned a parking space, but not both.

Other types of constraints

Click to show or hide information. Frequency

Use a frequency constraint to restrict the number of times a particular value (or combination of values) can occur in the population of one or more roles in a given predicate.

Frequency constraints can specify:

  • A specific value.
  • A range of values.
  • A minimum value.

You can create both internal frequency constraints and external frequency constraints.

Frequency constraint examples.

A Internal frequency constraint.

B External frequency constraint.

The following are instances of when to use frequency constraints:

  • Supposes there is a spanning uniqueness constraint on the fact type "Student enrolled in Subject on Date. If a student may enroll in a subject at most twice, create an external frequency constraint of "<=2" on the pair of roles played by student and subject.
  • If a team must have exactly nine players, create a frequency constraint that has a minimum and maximum value of 9 on the role played by the team.
  • If a team must have a minimum of five players but no more than twelve players, create a frequency constraint that has a minimum value of 5 and a maximum value of 12 on the role played by the team.
  • If a team must have a minimum of nine players and there is no restriction on the maximum number of players, create a frequency constraint that has a minimum value of 9 and no upper limit on the role played by the team.

Click to show or hide information. Index

An index constraint is an annotation to improve performance in a physical database and is not a true conceptual constraint. When you build a logical model based on your conceptual model, an index constraint is mapped to a non-unique index in a table.

You can apply an index constraint to one or more roles in one or more predicates, as long as all the predicates involved in the index share a single object type.

Index constraint examples.

A Internal index constraint.

B External index constraint.

When you apply an index constraint to more than one role, a non-unique index is generated for the combination of columns to which the roles map.

The following are typical facts for a database:

Person(id) lives at Address(code)

Person has FirstName

Person has LastName

To support searches based on the combination of a person's first and last names, apply an index constraint spanning the pair of roles played by FirstName and LastName. To support searches only on a person's address, apply the index constraint on the role played by Address.

The index constraint causes a non-unique index to be built for the column pair (LastName, FirstName). If you are searching for persons by entering their last and first names, this index ensures that you find their details quicker, because it builds an ordered tree in RAM based on LastName and FirstName that has pointers to the relevant rows of the table.

Click to show or hide information. Value

Use a value constraint to define the set of allowable values for an entity object type. You can define specific values or, in the case of numeric object types, a range of values.

Value constraint example.

Value constraint.

For instance, if you can create an object type for which the only allowable values are Male and Female, you can enter both words in the value constraint. Then, when the database is built, no other value can be entered for that database object.


Add a constraint (ORM)

Click to show or hide information. Add an internal or external constraint using the Add Constraint menu command

  1. Select the predicate(s) containing the roles to which you want to add one or more constraints, and then on the Database menu, click Add Constraint.

Click to show or hide information. Tip

You can also right-click the predicate(s) and click Add Constraint.

  2. In the Add Constraint dialog box, in Constraint type list, click the constraint you want.

Notes

  • For uniqueness constraints, select the Primary check box if you want this to be the basis for primary identifiers.
  • For subset, exclusion, or equality constraints, if there is more than one role at each end of the constraint, increase the number in the Number of roles at each end box to equal the number of roles.
  • For frequency constraints, in the Minimum and Maximum boxes, type the minimum and maximum number of times you want each object to play the role you specify.
  3. To indicate the sequence of the roles in the constraint, under Select the role box of each role in the constraint, click each role box in the appropriate sequence.

A number appears in each role box as you select it.

  4. Review the constraint by reading the verbalizer text in the bottom box. If the text is not what you expected, click Reset to clear all the settings in the dialog box and start over.

Note The constraint type defaults to Uniqueness whenever you click the Reset button.

  5. When the verbalizer text for the constraint is correct, do one of the following:
  • Click OK to add the new constraint and close the dialog box.
  • Click Apply after each constraint you add, and then click Close when you've added all the constraints you want.

Click to show or hide information. Add an internal or external constraint using the Database Properties window

  1. On the drawing page, double-click the predicate shape to open the Database Properties window.
  2. In the Categories list, click Constraints.
  3. Click Add Internal or Add External.
  4. In the Add Constraint dialog box, in the Constraint type list, choose a constraint type.

Notes

  • For uniqueness constraints, select the Primary check box if you want this to be the basis for primary identifiers.
  • For subset, exclusion, or equality constraints, if there is more than one role at each end of the constraint, increase the number in the Number of roles at each end box to equal the number of roles.
  • For frequency constraints, in the Minimum and Maximum boxes, type the minimum and maximum number of times you want each object to play the role you specify.
  5. Under Select the role box of each role in the constraint, click the appropriate role box(es).

A number appears in each role box as you select it to indicate the sequence of the roles in the constraint.

  6. Review the constraint by reading the verbalizer text in the bottom box. If the text is not what you expected, click Reset to clear all the settings in the dialog box and start over.

Note The constraint type defaults to Uniqueness whenever you click the Reset button.

  7. When the verbalizer text for the constraint is correct, do one of the following:
  • Click OK to add the new constraint and close the dialog box.
  • Click Apply after each constraint you add, and then click Close when you've added all the constraints you want.

Note You can also create a uniqueness constraint in the Database Properties window by clicking Examples in the Categories list. Enter example data for your fact, click Set UC Constraints, click Apply UC Constraints, and then click Close.

Click to show or hide information. Add an internal constraint using the Fact Editor

  1. On the Database menu, point to View, and then click Fact Editor to open the Fact Editor.
  2. On the Fact tab, under Input style, click Guided, and then select one of the following styles based on the type of constraint you want to create:
Constraint type | Guided input style
Frequency constraint | Binary, Ternary, or Quaternary
Mandatory constraint | Ternary or Quaternary
Uniqueness and mandatory constraint | Binary
Uniqueness constraint | Ternary or Quaternary

Note If you're an advanced user, you can select the Freeform input style for faster input. Select the object type delimiter you want to use (Capitalized or [bracketed]) and then type the text for the fact.

  3. Click the Constraints tab, and then click the button that matches the constraint you want to create.
Constraint type | Button
Frequency constraint |
Mandatory constraint |
Uniqueness and mandatory constraint |
Uniqueness constraint |
  4. Do one of the following, according to the constraint you want to create:

For this constraint type…

Do this…

Frequency constraint

Click New, select the role the constraint is for, enter the range of values, and then click OK.

Mandatory constraint

Select each role that is mandatory for an object type, and then press the spacebar to add a red dot next to the role.

Uniqueness and mandatory constraint

Select the appropriate responses to the questions. Click Rephrase to view an alternative wording of each question.

Optional: To create a primary uniqueness constraint, select an option from the Primary Uniqueness list.

Uniqueness constraint

Select each role combination that is unique, and then press the spacebar to turn the role combination yellow.

Optional: To create a primary uniqueness constraint, click Make Primary.

  5. Review the constraint in the box at the bottom of the Fact Editor, and then click OK.

Click to show or hide information. Add a ring constraint using the Fact Editor

  1. On the Database menu, point to View, and then click Fact Editor to open the Fact Editor.
  2. On the Fact tab, from the Object Name lists, choose the object type with the ring constraint.
  3. Under Input style, for Guided, select Binary, Ternary, or Quaternary.

Note If you're an advanced user, you can select the Freeform input style for faster input. Select the object type delimiter you want to use, Capitalized or [bracketed], and then type the text for the fact.

  4. Click the Constraints tab, and then click the Ring Constraint button.

  5. Click New, click the ring constraint in the diagram that represents the ring constraint you want to apply, and then click OK.
  6. Review the constraint in the box at the bottom of the Fact Editor, and then click OK.


Remove a constraint (ORM)

  1. Double-click the predicate associated with the constraint to open the Database Properties window.
  2. In the Categories list, click Constraints.
  3. Select the constraint you want to remove, and then click Remove.


Enter example data for a fact (ORM)

  1. On the Database menu, point to View, and then click Fact Editor to open the Fact Editor.
  2. If you haven't already done so, enter a new fact type on the Fact tab.
  3. Click the Examples tab.

The number of columns in the Examples tab matches the arity of the fact type you are defining or editing. (You set arity on the Fact tab in the Guided option.)

  4. Enter a significant population of example data.

Press TAB and SHIFT+TAB to move from one column to another.

  5. Click Analyze.

The example data you enter is analyzed and the correct uniqueness constraints are suggested for your fact type.

  6. Review the errors and warnings, click Close, and then add or change your example data based on the error or warnings.
  7. Click OK.


Analyze example data for a predicate (ORM)

  1. Open the ORM Source Model file that represents your model.
  2. Double-click the predicate whose sample data you want to analyze, and then, in the Database Properties window, in the Categories list, click Examples.
  3. Type the example data, if you have not already done so.
  4. Click Analyze.
  5. Review the results of the analysis, including any suggested changes, warnings, or errors.

If any errors are found, the Apply UC Constraints button does not appear. You must correct the error and click the Analyze button again to continue.

  6. Do one of the following:
  • If you want to apply the suggested uniqueness constraint, click the Apply UC button.
  • If you do not want to make any changes to the predicate, click the Close button.

The ORM source model is updated automatically.


Open the Fact Editor (ORM)

Do one of the following:

  • On the Database menu, point to View, and then click Fact Editor.
  • If the Business Rules window is not already open, on the Database menu, point to View, and then click Business Rules. On the Fact Types tab, double-click a fact.


Move a mandatory constraint dot to the role end (ORM)

  1. Click the role with the mandatory constraint.
  2. Click the role again, right-click it, and then click Mandatory on role.

The mandatory constraint dot moves to the role end.

Click to show or hide information. Tip

If an object type plays many roles, you may want to move the mandatory constraint dot to the role end so that you can more clearly see which roles are mandatory.


Hide or redisplay a constraint (ORM)

Click to show or hide information. Hide a constraint

  1. Click the constraint you want to hide.
  2. Press DELETE.
  3. When asked if you want to remove the selected item from the underlying model, click No.

Click to show or hide information. Redisplay a constraint

Right-click the predicate with the constraint you want to redisplay and click Show All Constraints.


About object-relational types in ORM models

Click to show or hide information. Composite types and collection types in a logical model

A logical model can have both composite data types and collection types.

  • Composite data types combine one or more existing data types to create a new data type.
  • Collection types are groups of values stored in the same field.

Click to show or hide information. Composite types and collection types in an ORM conceptual model

To support conceptual modeling of object-relational databases, you can flag elements in an ORM conceptual model that you want to map to composite types and collection types in a logical model.

You can:

  • Set a composite type property for object types. Composite types map directly to a specified SQL3 type at the logical level. (By default, non-composite types and non-nested object types map to built-in data types.)
  • Set a composite type property for predicates when the predicate is a many-to-many binary predicate or has an arity of 3 or more.
  • Define roles as collection types to control collection-type mapping in the logical model. (Predicates map to tables, columns, and relationships in a logical model.)

There is no graphical representation for composite types or collection types in an ORM model, but they are mapped with no loss of information to the appropriate type in a logical model.


About composite types in ORM models

In an ORM model, you can model named row types, unnamed row types, domains, and distinct types by setting the appropriate property for an entity object type.

Click to show or hide information. Named row types

In an ORM model, a valid named row type is simply an object type that has its own functional roles and for which the named row type property is set. Any entity object type can be a row type if it is part of a complete fact and not part of a nested scheme.

Named row types:

  • Allow you to create models with reusable ORM fragments based on a single object type.
  • Are used for commonly occurring groups of fact types.

Click to show or hide information. Unnamed row types

Unnamed row types are created the same way as named row types. Unlike named row types, unnamed row types are not identified within the system as persistent type storage.

In an ORM conceptual model, the only difference between an unnamed row type object type and a named row type object type is the option you choose for the object type.

Click to show or hide information. Domain types and distinct types

Domain types and distinct types are created the same way as named row types.

You use domain types and distinct types to prevent columns with similar data qualities but that are distinct in nature from being operated on or compared.

For example, in your ORM model you might have two object types that are both numeric data types, but the information in each column has no relative bearing to each other. To prevent math operations between the two columns in the logical model, you declare them as distinct types.

Declare an object type as a:

  • Domain type when the data type is a built-in type.
  • Distinct type when the data type for that object type is another complex type.

Click to show or hide information. Composite types deleted from an ORM model

A named row type in ORM is deleted when you do either of the following:

  • Delete the defining object type.
  • Click Does not result in a composite type in the Database Properties window for the Composite Type category.

When you delete the object type and update a project containing the ORM source model:

  • The table based on the object type is deleted.
  • References or relationships based on the deleted row type are deleted.

Click to show or hide information. How composite types map to physical types

Each object type in an ORM conceptual model for which a composite type property is set maps to a corresponding named type when you build a logical model.

When a named row type property is set on an object type, all functional roles are mapped to the corresponding typed table. Many-to-many (m:n) binary facts are excluded from mapping to the named row type's definition. However, if there is a collection type property set on an m:n binary predicate, that predicate is also included in the named type grouping.

Note There is no limit to the aggregation support or nesting of row types. A row type can contain other row types and collection types to any level.

Click to show or hide information. Excluding roles from a row type

When you set the row type property for an object type, all the functional roles of the object type are associated with the row type. The only way to exclude roles from the role type definition is to create an intermediary object type.

To create an intermediary, you create another object type and branch off the row type aggregates.

Click to show or hide information. Example: Row types in conceptual models

A common example of row types in ORM is an Address object type that can be used in multiple places in a model but that has no identification scheme of its own. It is sometimes more desirable to have an object type placeholder available for an Address that pulls in all of its functional fact types.


About collection types in ORM models

Click to show or hide information. Sets

A set is a collection of unordered, nonrepeating group values. In other words, the order of the values in the collection does not matter, but the uniqueness of the values is important. For example: (b1, b2, b3).

Click to show or hide information. Lists

A list is a collection of ordered and possibly repeating values. In other words, the order of the values in the collection is important. For example: (b3, b2, b1, b2, b3).

Click to show or hide information. Multisets

A multiset is a collection of unordered and possibly repeating values. For example: ( (b3, b2), (b1), (b2, b3) ).

Click to show or hide information. Where collection types can and cannot exist

Collection types can be declared only as properties of fully spanned, m:n uniqueness constraints over a binary predicate or any role in a ternary or higher predicate.

Collection types cannot be defined:

  • On a unary predicate.
  • On functional roles.
  • On the many side of a many-to-one (m:1) binary relationship.
  • Over 1:1 binary predicates.

Click to show or hide information. Notes about collection types

  • Unlike row types, collection types are properties of a role, not an object type.
  • A role can pertain to any object type, so there are no restrictions on the kinds of object types or physical data types used in a collection-based role.
  • By default, roles are single-valued, meaning no collection type property applies.


Define a composite type (ORM)

  1. Double-click the object type shape or predicate shape you want to edit to open the Database Properties window.
  2. In the Categories list, click Composite Type.
  3. Under Mapping Option, choose the composite type you want. Select one of the following types based on the selected shape:
Shape | Composite types available
Object type | Named row type, Unnamed row type, Domain, Distinct type
Predicate | Named row type
  4. Do one of the following based on the composite type you are creating:
Composite type | Do this
Distinct type | In the Distinct type name box, enter the name for the logical type to be generated by the mapping process.
Domain | In the Domain name box, enter the name for the logical type to be generated by the mapping process.
Named row type | In the Row type name box, enter the name for the logical type to be generated by the mapping process. Select the Generated type table check box to create a separate typed table from the object type when it is mapped to a logical model.


Define a role as a collection type (ORM)

  1. Double-click the predicate that has the role connector to which you want to add a collection type to display the Database Properties window.
  2. Click the role connector once to subselect it.
  3. In the Database Properties window, in the Categories list, click Collection. Under Collection Type, click the type of collection you want to add to the role.


Database Properties for Object Type shape (Definition)

Use these options to specify the name of the object type and its general nature.

Click to show or hide information. Name

Type a name for this object. Typically, names are unique across a model. When you use duplicate object names, you must provide a unique value for Name space to differentiate the objects at the project level.

Click to show or hide information. Kind

Select the object type: Entity or Value.

Click to show or hide information. External

Select this check box to indicate that an object is (or will be) defined in another source model within a project.

You can classify an object type as external until you build the model either independently or as part of a project. Then you must resolve it from another instance.

Click to show or hide information. Name Space

Optional: Type a name space to distinguish identically named objects.

Click to show or hide information. Independent

Select this check box to specify that an entity is intended to be a lookup (reference) table (for example, the names of all countries), whether or not they play fact roles. Typically, leave this box clear.

If this box is selected, the object type is always used to create a separate logical table when you build the logical model.

If the object type is also a named row object type, the table generated is a typed table based on the type used to create it.

One guide to independent status is the absence of mandatory roles.

Click to show or hide information. Personal Pronoun

Select this check box to replace the pronoun "its" with the pronoun "his/her" in verbalization.


Database Properties for Object Type shape (Ref Mode)

Use these options to name the collection of values by which each entity in a set is identified. In other words, the reference mode specifies how an entity object type instance is identified. You use these values when you map the conceptual model to a logical model.

A reference mode identifies a unique instance of an object type; it appears in parentheses after the object type name. For example, for an object type called Person, you could identify an individual Person by name, by surname, by identifying code, or by social security number. If you use an individual's surname to identify members of the Person set, Person(surname) is appropriate.

Click to show or hide information. Reference

Type a reference mode identifier. Applies only to entity object types.

Use a word, abbreviation, or symbol that suggests the means by which you want to identify the given entity.

For example, when employees are identified by a unique number, you could use num, #, or id, values that are often used in defining a physical database. Use characters that are valid in your DBMS.

Although names such as id, code, and name might be shared among several object types, the scope of each applies only to the particular object type.

Click to show or hide information. Type

Select the behavior of the reference identifier.

Type | Description
No reference mode | Allows the entity object type's primary identification to be defined explicitly using the long form of a reference.
Identification | Default. Stores the object type as a fact with the predicate "…is identified by…"
Measurement | Stores the object type as a fact with the predicate "…is measured in…," where the word Value is appended to the reference mode.
Formatting | Stores the object type as a fact with the predicate "…is recorded as…". Useful for values that can appear in different forms, such as dates: MDY, YMD, and DMY.

Click to show or hide information. Use Document's Setting

Click to use the default reference modes defined for the document in the ORM Document Options dialog box. To override the default setting for any particular object type, select one of the other three options in this group.

Click to show or hide information. Do Not Use For Naming

Click to not use the reference mode designation when naming columns in the mapped logical model.

Click to show or hide information. Add To object Type Name

Click to incorporate the reference mode into the object type name when naming columns in the mapped logical model.

For example, an object type named Person by default generates a table with the name Person. When this option is clicked, the reference mode ("Name") is appended to the object type name, resulting in an object type name of PersonName.

Click to show or hide information. Use As Column Name

Click to use the reference mode as a column name in the mapped logical model.

Because a value for any reference mode by definition serves to identify an object, any table generated from a model has at least one identifying column. This column is equivalent to the object type reference mode, because the reference mode identifies any element in the set of possible object type values.


Database Properties for Object Type shape (Data Type)

Click to show or hide information. About Data Type options for object types

Use these options to examine or modify how the ORM Solution maps its portable data types to your target DBMS when you build a logical model based on an ORM model.

Data types in a conceptual model are based on a generic set of data types. When your model is built for a particular DBMS, the Database Model Diagram template must translate the generic (or portable) data type into one that suits the target DBMS.

This tab also reflects any user-defined data types, which you can create in the User-Defined Types dialog box. You can create user-defined data types that adhere to standards within your organization and then use the user-defined data types within your model.

Show Portable Data Type

Click to change the options on the Data Type tab to work with portable (generic) data types.

These data types are automatically mapped to corresponding data types in your target DBMS.

Click to show or hide information. User Defined

Choose a user-defined data type.

To define a new data type, on the Database menu, click User-Defined Types.

Click to show or hide information. Category

Choose a portable data type category.

The data type definition you construct here automatically maps to the nearest native data type of your DBMS.

Click to show or hide information. Type

For the selected category, choose an appropriate data type.

Note Some values for Type also require Size, Length, Precision, or Scale values.

Click to show or hide information. Size

For the selected category and type, choose a size.

Click to show or hide information. Length

Type the number of digits used to express a value.

Click to show or hide information. Precision

Type the number of integers used to express a value.

Click to show or hide information. Scale

Type the number of digits to the right of the decimal point.

Click to show or hide information. Allow Numeric Operations?

Select this check box to specify that numeric operations will be allowed with this column when it is mapped to a DBMS.

Show Physical Data Type

Click to change the options on the Data Type tab to work with the physical data types of the default database driver.

Click to show or hide information. Data Type

Shows the physical data type (native to the underlying DBMS) that the selected portable data type will map to. This option can be overridden locally.

Click to show or hide information. Edit

Click to change the data type listed in the Data type box.

Click to show or hide information. Default Driver

Identifies the default Visio database driver. This driver determines how portable data types are mapped to physical data types. It also determines what physical data types are available for the particular DBMS.

Click to show or hide information. Allow Numeric Operations?

Select this check box to specify that numeric operations will be allowed on this column when it is mapped to a DBMS.


Database Properties for Object Type and Predicate shape (Composite Type)

Use these options to specify how object types are mapped to named and unnamed row types in a logical model diagram. Row types create composite data types that you can use in object-relational database models to specify the data type.

Named row types are based on the SQL3 specification of tables, called typed tables, and are identified within the system as persistent type storage. Unnamed row types are not identified as persistent type storage.

Click to show or hide information. Does Not Result In A Composite Type

Click to specify that object types map to built-in data types in a logical model. (This is the default option.)

Click to show or hide information. Named Row Type

Click to specify that the object type maps to a named row type that has its own functional roles in a logical model that supports object-relational types.

There is no notation for row types in an ORM model.

Click to show or hide information. Row Type Name

This box is available when Named Row Type is clicked. Type the name for the logical type to be generated by mapping.

Click to show or hide information. Generate Typed Table

This check box is available for Object Type shapes when Named Row Type is clicked. Select this check box to create a separate typed table from the object type when it is mapped to a logical model.

Click to show or hide information. Unnamed Row Type

Click to specify that the object type maps to an unnamed row type in a logical model.

In an ORM model, the only difference between an object type set as an unnamed row type and one set as a named row type is this option. Unlike named row types, unnamed row types are not identified within the system as persistent type storage.

Click to show or hide information. Domain

Click to specify that the object type maps to a domain in a logical model that supports object-relational types.

Click to show or hide information. Domain Name

This box is available when Domain is selected. Type the name for the logical type to be generated by mapping.

Click to show or hide information. Distinct Type

Click to specify that the object type maps to a distinct type in a logical model that supports object-relational types.

Click to show or hide information. Distinct Type Name

This box is available when Distinct Type is selected. Type the name for the logical type to be generated by mapping.


Database Properties for Object Type shape (Subtype)

Use these options to define an object type as a subtype that inherits all the properties of its parent.

By default, the characteristics of a subtype object type are included in those of its parent. In other words, instances of a subtype object type are included in the tables that contain instances of the supertype (parent).

You can map subtype instances independently of supertype instances.

In cases where a subtype has more than one supertype, you can also specify which object type is to be recognized as the parent.

Click to show or hide information. Map To Separate Table

Select this check box to create separate tables for subtype entities, resulting in faster response to some queries about the subtype entity, but slower response to queries that involve the supertype and sibling subtypes.

If you select this check box, enter a reference mode in the Ref Mode category, and enter data type characteristics in the Data Type category.

Click to show or hide information. Create Table Inheritance

Select this check box to specify that the object type inherits the characteristics or settings of the table on which it is based. If the characteristics of the table change, the object type based upon it inherits those characteristics.

Click to show or hide information. Primary Supertype

When a subtype has more than one supertype (that is, when the subtype has multiple inheritance), click the primary supertype.

Click to show or hide information. Subtype Definition

Describes the subtype and its relationship to its supertype. You can include this description in reports that you create.


Database Properties for Object Type shape (Value)

Use these options to define the set of allowable values for an entity object type. You can define specific values or, in the case of numeric object types, a range of values.

For example, if you created an object type for which the only allowable values are Male and Female, you can enter both words in the Defined Values/Ranges list. Then, when the database is built, no other value can be entered for that database object.

Click to show or hide information. Range

From Type the minimum value in a range.

To Type the maximum value in a range.

Click to show or hide information. Value

Type an individual value to use as the value constraint.

Click to show or hide information. Add

Click to add the values under Range or Value to the list of Defined values/ranges.

Click to show or hide information. Remove

Click to remove the selected item in the Defined values/vanges box.

Click to show or hide information. Defined Values/Ranges

Lists all value constraints you have defined.


Database Properties for Object Type shape (Nested Roles)

Use these options to describe the relationships between a nested object type (also called an "objectified fact type") and its role players.

A fact can be objectified (and named) so that it can be treated as an object type. For example, by objectifying the fact "Student turns in Paper" as "Assignment," the entire fact can be treated as an object type. Now the new object type can be used to define a new fact, such as "Assignment receives Grade."

Click to show or hide information. Nested Role Readings

Shows the implied relationships between the nested object type and its component object types. For instance, if we objectify the association "Retailer sold Product" as "Sale," the implied relationships are verbalized as "Sales involves Retailer" and "Sales involves Product."

Click to show or hide information. Relationship Text

Verbalizes the relationship between the nested object type and its component object type. To change the text, type a new phrase. The relationship text is the predicate.

This text also appears in the Verbalizer window, in reports, and in the Fact Editor dialog box.


Database Properties for Object Type and Predicate shape (Notes)

Click to show or hide information. Notes

Type notes about the object type or predicate. Notes can appear in reports and in the Verbalizer window.


Database Properties for Predicate shape (Definition)

Use these options to select the arity (number of roles) of a fact, specify a name space, or define the predicate as an external predicate.

Click to show or hide information. Arity

Specify the arity (number of roles) of the fact.

Click to show or hide information. Name Space

You can include a name space to distinguish identically named objects.

Click to show or hide information. External

Select this check box to indicate the predicate as external.

Use an external fact to define additional instances of a fact whose primary definition resides in another source model associated with a project.


Database Properties for Predicate shape (Readings)

Use these options to describe the forward and inverse reading for the fact. Make the predicate text as descriptive of the relationship as you want; more descriptive text makes maintenance of the model easier.

The text you provide for role boxes is called the conceptual name of the predicate. When the predicate text is used to create a table column name, the resulting value is called the physical name. Both names can be different and still refer to the same fact.

Click to show or hide information. Text

Type the forward reading of the predicate (for example, "works for").

This text is sometimes used to form table and column names.

This option appears only for unary and binary predicates.

Click to show or hide information. Role Name (role n)

Type a conceptual name for the role. For example, the two roles of the fact type "Person reports to Person" might be named "reporter" and "supervisor." When the conceptual model is mapped to a logical model, a role name may often provide a natural physical name for the mapped column.

Click to show or hide information. Inverse Text

Type the inverse reading of the predicate (for example, "supervises").

This option appears only for binary predicates.

Click to show or hide information. Reading

Shows the forward reading of a fact of ternary arity and beyond.

These facts may have multiple readings as well, one starting at each role.

This option does not appear for unary predicates.

Click to show or hide information. Text Use For Naming

Select whether to use the document settings for the tables and columns created by mapping this predicate when you build a logical model.

  • Use document's settings Click to follow the settings in the Document Options dialog box (Miscellaneous tab).
  • Use when possible Click to override a setting and not use predicate text if the predicate text does not map to an empty string because of abbreviations.
  • Do not use Click to not use the predicate text to create the column names and override any document settings.

To set the defaults for a document, on the Database menu, point to Options, and then click Document.


Database Properties for Predicate shape (Examples)

Enter examples to check the correctness of the constraints. Each row in the Examples grid represents one instance of data from all the object types that play a role in the fact.

Click to show or hide information. Grid

Type example instances of the fact. Each row in the Examples grid represents one instance of data from all the object types that play a role in the fact. The number of columns you see matches the arity of the predicate you are defining or editing.

Press TAB to move forward one column. Press SHIFT+TAB to move back one column.

Click to show or hide information. Analyze

Click to analyze the example data you entered, check the uniqueness constraints of the fact, and display the results in the Example Analysis Results dialog box.

Click to show or hide information. Set UC Constraints

Click to apply any uniqueness constraints that are evident from the example data.

Errors and warning messages are displayed in the Example Analysis Results dialog box.


Database Properties for Predicate shape (Derived)

Use these options to specify a derivation rule for the predicate.

Some facts can be derived from mathematical calculations (referred to as derivation rules) that involve other facts in the model. For example, a common derivation rule calculates a sum.

An asterisk appears next to the predicate of a derived fact in the model.

Click to show or hide information. None

Click to indicate that this fact does not derive from other facts. This is the default.

Click to show or hide information. Derived

Click to indicate that this fact derives from other facts. The resulting data is not stored in the database, but is recalculated for each row.

Click to show or hide information. Derived And Stored

Click to indicate that this fact derives from other facts. The resulting data is then stored in the database.

Storage space is sacrificed to gain speed of access.

Click to show or hide information. Rule

Type the rule by which the predicate is derived.

This rule appears in reports and in the Verbalizer window.


Expand all contracted text Show All

<constraint type > Properties dialog box (Notes)

Click to show or hide information. Notes

Type notes about the constraints in your model. Notes can appear in reports and in the Verbalizer window.


Uniqueness Constraint Properties dialog box (Definition)

Use the options in this category to define the selected uniqueness constraint as the primary identifier of the object type. By default, uniqueness constraints do not imply primary identification of an object type.

Click to show or hide information. Represents The Primary Identification Scheme

Select this check box to set this fact as the primary identifier of an object type.

At times, more than one scheme can uniquely identify an object type. You can use this option to select your identification scheme.

When either you or your model provides more than one primary identification scheme, one is chosen arbitrarily.

Click to show or hide information. Mapping Option

Specify whether to map the object type as the primary key, as an alternate key, as a non-unique index, or not as a key in the logical model.


Mandatory Constraint Properties dialog box (Definition)

Click to show or hide information. Ignore Mandatory Constraint When Mapping

Specifies that when the object type is mapped, this constraint is ignored.


Ring Constraint Properties dialog box (Definition)

When you first apply a ring constraint, it is labeled Undefined. Use these options to define the type of ring constraint.

Click to show or hide information. Ring Type

Choose an option from the Ring Type list to specify the ring constraint type.

Click to show or hide information. Illustration

You can also click in the ring constraint diagram to specify the ring constraint type.


Frequency Constraint Properties dialog box (Definition)

Use these options to define a frequency constraint, which restricts the number of times that a shared role can be played.

Click to show or hide information. Minimum

Indicates the minimum frequency of this role. Each object that plays this role must play it at least the number of times specified here.

Click to show or hide information. Maximum

Indicates the maximum frequency of this role. Each object that plays this role must play it at most the number of times specified here.


Database Properties for Predicate shape (Constraints)

Lists all constraints associated with the selected predicate.

Click to show or hide information. Add Internal

Click to open the Add Constraint dialog box in which you can add new internal constraints for the selected predicate.

Note When you click Add Internal, the Add Constraint dialog box displays only the relationship associated with the selected predicate.

Click to show or hide information. Add External

Click to open the Add Constraint dialog box in which you can add new internal or external constraints for the selected predicate.

Note When you click Add External, the Add Constraint dialog box displays relationships that share an object type with the selected predicate.

Click to show or hide information. Remove

Click to delete the selected constraint.

Click to show or hide information. Edit

Click to open a dialog box specific to the type of constraint you created in which you can edit the selected constraint.


Database Properties for the Role box on the Predicate shape (Collection)

Use these options to model collection types of an object relational database. In ORM, you can annotate roles that have a uniqueness constraint to indicate support for sets, lists, and multi-sets.

Collection types do not appear on the drawing page.

Collection types are properties of a role, not of an object type, because a role can pertain to any object type. Therefore, no restrictions are placed on the kinds of object types or physical data types used in a collection-based role.

When you build a logical model based on your ORM model, collection types are mapped with no loss of information.

Click to show or hide information. Unordered, Non-Repeating Group Of Values (Set)

Click to specify that the role maps to a set collection type. For an m:n uniqueness constraint, the set nests the relation in a table in the mapped logical model.

Click to show or hide information. Ordered Group Of Values (List)

Click to specify that the role maps to a list collection type. When you build the logical model, the appropriate data type is created with no loss of information.

If you provide example data on the Examples tab of the Database Properties for Predicate Shape dialog box to represent a list (duplicate values, ordered elements), an error occurs, because duplicate values violate the definition of an elementary fact in ORM.

Click to show or hide information. Unordered, Repeating Group Of Values (MultiSet)

Click to specify that the role maps to a multi-set collection type. When you build the logical model, the appropriate data type is created with no loss of information.

If you provide example data on the Examples tab of the Database Properties for Predicate Shape dialog box to represent a multi-set (duplicate values, unordered elements), an error occurs, because duplicate values violate the definition of an elementary fact in ORM.

Click to show or hide information. Single Value (Column)

Click to specify that the role maps to a column containing a single value. This is the default for relational databases.


Fact Editor dialog box (Fact tab)

Use the options on this tab to enter the details about fact types for your data model. The Fact Editor converts the fact types you enter into the correct symbols and constraints on your diagram.

You can specify the style by which new fact types are entered. The natural language verbalization of the object type names and the predicate in the fact type appears at the bottom of this tab.

Click to show or hide information. Object Name

If Guided is clicked under Input Style, this box appears. Click an existing object type in the model from the list, or type a new object name in the box.

Click to show or hide information. Relationship

If Guided is clicked under Input Style, this box appears. Type the forward text describing the relationship.

Click to show or hide information. Object Name

If Guided is clicked under Input Style, this box appears. Click an existing object type in the model from the list, or type a new object name in the box.

Click to show or hide information. Inverse Relationship

If Guided is clicked under Input Style, this box appears. You can type the inverse text describing the relationship here.

Click to show or hide information. Freeform

Click to type the text of a fact type in a natural language syntax. Click either [bracketed] or Capitalized to indicate the name of an object type.

You must use the freeform input style if you are creating a fact type that has an arity greater than four.

Click to show or hide information. Guided

Click to type the text of a fact type into a guided form. Click the arity of the fact type to specify the contents of the guided form.

When you use this input style, you can reuse object type names in the Fact Editor.


Fact Editor dialog box (Object tab)

Use the options on this tab to classify new object types by selecting a kind (External, Entity, or Value), defining a reference mode for entity object types, and entering a description.

The natural language verbalization of the object type and its kind appears at the bottom of this tab.

Click to show or hide information. Select Object

Lists object types in the current fact type. The selected object type determines where all values on this page are applied.

Click to show or hide information. Object Kind

Click the object type kind:

  • External The object type is defined elsewhere.
  • Entity Entity type (has reference mode).
  • Value Value type (has no reference mode).

Click to show or hide information. Reference/Identifier

Type a reference mode identifier. Applies only to entity types.

Use a word that suggests the means by which you want to identify the given entity.

For example, when employees are identified by a unique number, you could use num or # or id, values that are often used in defining a physical database. Use characters that are valid in your DBMS.

Although names such as id, code, and name might be shared among several object types, the scope of each applies only to the particular object type.

Click to show or hide information. Ref Type

Click the function of the reference identifier.

No Reference Mode | Entity object type without reference.
Identification | Default. Stores the object type reference using the predicate text "…is identified by…".
Measurement | Stores the object type reference using the predicate text "…is measured in…," where the word Value is appended to the reference mode.
Formatting | Stores the object type reference using the predicate text "…is recorded as…". Useful for values that can appear in different forms, such as dates: MDY, YMD, DMY.

Click to show or hide information. Notes

You can type a description of the object type that is being defined. This information is for reference only.


Fact Editor dialog box (Examples tab)

Use this tab to enter examples that clarify constraints on the fact type. Each row in the grid represents one fact instance, so include instances of each object type that plays a role in the fact type.

The natural language verbalization of the fact type, using examples, appears at the bottom of this tab.

Click to show or hide information. Grid

Type sample instances of the fact type. The number of columns you see matches the arity of the predicate you are defining or editing.

Press TAB to move forward one column. Press SHIFT+TAB to move back one column.

Click to show or hide information. Analyze

Click to analyze the example data you entered, check the uniqueness constraints of the fact, and display the results in the Example analysis results dialog box.

Click to show or hide information. Set UC Constraints

Click to apply any uniqueness constraints that are evident from the example data.

Errors and warning messages appear in the Example analysis results dialog box.


Fact Editor dialog box (Constraints tab)

Use the options on this tab to determine how to apply internal uniqueness and mandatory constraints to the current fact type.

The natural language verbalization of the constraint specification appears at the bottom of this tab.

Click to show or hide information. Buttons

Frequency constraint
Restricts the number of times a particular value (or set of values) can occur in the population of one or more roles.

Available when you select the following from the Guided list on the Fact tab: Binary, Ternary, or Quaternary.

Mandatory constraint
Specifies that the object type is not optional—every instance of an object type's population must play that role.

Available when you select one of the following from the Guided list on the Fact tab: Ternary or Quaternary.

Ring constraint
Specifies that a pair of roles are connected to the same object type.

Available when a role connects the same object type and when you select one of the following from the Guided list on the Fact tab: Binary, Ternary, or Quaternary.

Uniqueness constraint
Specifies that the values for the selected fact type must be unique—the fact type cannot have duplicate values.

Available when you select one of the following from the Guided list on the Fact tab: Ternary or Quaternary.

Uniqueness and mandatory constraint
Specifies that the values must be unique (no duplicate values) and that the object type is not optional.

In the Fact Editor, you create the constraint by selecting the text (above Rephrase) that answers each Constraint Question.

Available when you select the following from the Guided list on the Fact tab: Binary.

Binary fact type

Click to show or hide information. Constraint Question #1

For the first object type in the fact type, phrases a question designed to help you create the appropriate constraints.

Answer the question by clicking one of the following options in the list box to the right of the question box:

  • Zero or One Creates an internal uniqueness constraint.
  • Zero or More Creates no constraints.
  • Exactly One Creates an internal uniqueness and a mandatory constraint.
  • One or More Creates a mandatory constraint.

Click to show or hide information. Constraint Question #2

For the second object type in the fact type, phrases a question designed to help you create the appropriate constraints.

Answer the question by clicking one of the following options in the list box to the right of the question box:

  • Zero Or One Creates an internal uniqueness constraint.
  • Zero Or More Creates no constraints.
  • Exactly One Creates an internal uniqueness and a mandatory constraint.
  • One Or More Creates a mandatory constraint.

Click to show or hide information. Rephrase

Click to change the phrasing of the question in the corresponding Constraint Question box.

Click to show or hide information. Primary Uniqueness

Select how an object type that is primarily identified by two or more reference predicates is displayed in the diagram. If None, no primary identifier has been determined yet.

The fact diagram shows how any uniqueness constraints are applied.

Ternary or quaternary fact type

Click to show or hide information. Check All Role Combinations Which Are Unique (Toggle Using Space Bar)

Click a role combination and then press the space bar to indicate which role combinations result in unique data.

Click to show or hide information. Make Primary

Click to specify that the combination of data is unique and that you want it to be a primary key.


Fact Editor dialog box (Advanced tab)

Use the options on this tab to define a fact as an external fact, create a nested object type, or create a derived fact.

The natural language verbalization of the fact with both forward and inverse predicate text appears at the bottom of this tab.

Click to show or hide information. Notes

Displays notes about the fact. Type any notes you want to make. You can include notes in reports about the model.

Click to show or hide information. Objectify / Nest Fact As

Type the object type name that is produced by the nesting of this fact.

Click to show or hide information. Derivation Of Fact

Select whether the fact type is derived from one or more other fact types.

  • Derived Click to note the calculation without storing the result in the database.
  • Derived and stored Click to note the calculation and store the result in the database.

Click to show or hide information. Derivation Rule

Shows the rule to use in deriving the fact.

You can type a derivation rule in any way you prefer. All operator characters are accepted. For example, the following rules are all acceptable:

Total income equals earned income plus other income

Total income = earned income + other income

Earned income + other income = total income

Click to show or hide information. External Fact Type (This Fact Is A Proxy For A Fact Defined Somewhere Else)

Select to specify that the fact type is external.

To include multiple instances of a fact type in a model, one or more instances must be defined as external. Otherwise, you cannot include duplicate fact types.


Example Analysis Results dialog box

If the examples you entered violate or do not provide a significant sample for a uniqueness constraint, this dialog box opens and shows you the errors. If your example data contains errors or insufficient data, you must fix the errors and then click Set UC Constraints again before Visio can apply the constraint.

Click to show or hide information. Analysis Results

Lists the results of the analysis, including any errors or warnings.

Click to show or hide information. Apply UC Constraints

Click to add the constraints that are suggested by the analysis to the model.


ORM Document Options dialog box (Abbreviation tab)

Use the options on this tab to specify how to generate physical database names (column names) from conceptual names.

Click to show or hide information. Name

Type the name used in the physical database for the term in the Abbreviation column. If the Abbreviation column is blank, the word is ignored.

Click to show or hide information. Abbreviation

Type the name used in the conceptual model that will be mapped to the term in the Names column. If this column is blank, the word in the Names column is ignored.

Click to show or hide information. Defaults

Click to change the default settings:

  • Set As Sets the new settings as the document default settings.
  • Restore Resets the document settings to the way the settings were when you first opened the dialog box.
  • Restore Original Resets the document settings to the original default settings.


ORM Document Options dialog box (Prefix tab)

Use the options on this tab to specify how to generate physical database names (column names) from conceptual names.

Click to show or hide information. No Prefix (Column)

Click to specify that when you generate physical database names (column names) from conceptual names, no prefixes are used.

Click to show or hide information. Prefix With The First <#> Letters Of Table Name

Click to specify that when you generate physical database names (column names) from conceptual names, the first letters of the table name are added to the beginning of the column names.

Click to show or hide information. Custom Prefixes (Column)

Click to specify that when you generate physical database names (column names) from conceptual names, the letters you specify are added to the beginning of the column names, according to the table name.

Click to show or hide information. No Prefix (Table)

Click to specify that when you generate physical database names (column names) from conceptual names, the table names have no prefixes.

Click to show or hide information. Custom Prefix (Table)

Click to specify that when you generate physical database names (column names) from conceptual names, the letters you specify are added to the beginning of the table names.

Click to show or hide information. Defaults

Click to change the default settings:

  • Set As Sets the new settings as the document default settings.
  • Restore Resets the document settings to the way the settings were when you first opened the dialog box.
  • Restore Original Resets the document settings to the original default settings.


ORM Document Options dialog box (Suffix tab)

Use the options on this tab to specify how to generate physical database names (column names) from conceptual names.

Click to show or hide information. No Suffix (Column)

Click to specify that when you generate physical database names (column names) from conceptual names, no suffixes are used.

Click to show or hide information. Custom Suffixes (Column)

Click to specify that when you generate physical database names (column names) from conceptual names, the letters you specify are appended to the column names, according to the table name.

Click to show or hide information. No Suffix (Table)

Click to specify that when you generate physical database names (column names) from conceptual names, the table names have no suffixes.

Click to show or hide information. Custom Suffix (Table)

Click to specify that when you generate physical database names (column names) from conceptual names, the letters you specify are appended to table names.

Click to show or hide information. Defaults

Click to change the default settings:

  • Set As Sets the new settings as the document default settings.
  • Restore Resets the document settings to the way the settings were when you first opened the dialog box.
  • Restore Original Resets the document settings to the original default settings.


ORM Document Options dialog box (Capitalization tab)

Click to show or hide information. Column Names

Specifies the style of capitalization to use for column names.

  • Force Upper Click to change the capitalization to all uppercase.
  • Force Lower Click to change the capitalization to all lowercase.
  • Preserve Click to use the capitalization that you type.

Click to show or hide information. First Letter (Column)

Specifies the style of capitalization to use for the first letter of the column name prefixes.

  • Force Upper Specifies to change the capitalization to uppercase.
  • Force Lower Specifies to change the capitalization to lowercase.
  • No Change Specifies to use the capitalization that you type.

Click to show or hide information. Table Names

Specifies the style of capitalization to use for table names.

  • Force Upper Click to change the capitalization to all uppercase.
  • Force Lower Click to change the capitalization to all lowercase.
  • Preserve Click to use the capitalization that you type.

Click to show or hide information. First Letter (Table)

Specifies the style of capitalization to use for the first letter of the table name prefixes.

  • Force Upper Specifies to change the capitalization to uppercase.
  • Force Lower Specifies to change the capitalization to lowercase.
  • No Change Specifies to use the capitalization that you type.

Click to show or hide information. Defaults

Click to change the default settings:

  • Set As Sets the new settings as the document default settings.
  • Restore Resets the document settings to the way the settings were when you first opened the dialog box.
  • Restore Original Resets the document settings to the original default settings.


ORM Document Options dialog box (Miscellaneous tab)

Use the options on this tab to specify how to generate physical database names (column names) from conceptual names.

Click to show or hide information. Reference Mode

Specifies whether and how to use the object type reference modes when generating physical database names (column names) from conceptual names.

Click to show or hide information. Spacing Character

Specifies the character used to separate parts of a name when generating physical database names (column names) from conceptual names.

Click to show or hide information. Maximum Name Length

Type or select the maximum number of characters to use when generating physical database names (column names) from conceptual names.

Click to show or hide information. Use Predicate Text For Mapping Whenever Possible

Select to use the text in the predicate when the column and table names are created from conceptual names.

Click to show or hide information. Pluralize Table Names

Select to make table names plural when generating physical database names (table names) from conceptual names.

Click to show or hide information. Defaults

Click to change the default settings:

  • Set As Sets the new settings as the document default settings.
  • Restore Resets the document settings to the way the settings were when you first opened the dialog box.
  • Restore Original Resets the document settings to the original default settings.


New Frequency constraint dialog box

Click to show or hide information. Highlight All Roles Which Define This Constraint

Click the role (or values) that are being constrained. (These options are available only when you select Ternary or larger from the Guided list on the Fact tab.)

Click to show or hide information. Please Select The Role This Constraint Is Being Defined For

Click the role (or values) that are being constrained. (These options are available only when you choose Binary or Unary from the Guided list on the Fact tab.)

Click to show or hide information. Minimum

Type the minimum number of times that the values of the highlighted roles can occur.

Click to show or hide information. Maximum

Type the maximum number of times that the values of the highlighted roles can occur.


Edit Frequency Constraint dialog box

Click to show or hide information. Highlight All Roles Which Define This Constraint

Click the role (or values) that are being constrained. (These options are available only when you choose Ternary or larger from the Guided list on the Fact tab.)

Click to show or hide information. Frequency Constraint For Role

Lists the role (or values) that are being constrained. (This appears only when you choose Binary or Unary from the Guided list on the Fact tab.)

Click to show or hide information. Minimum

Type the minimum number of times that the values of the highlighted roles can occur.

Click to show or hide information. Maximum

Type the maximum number of times that the values of the highlighted roles can occur.


Import VisioModeler IMO File dialog box

Click to show or hide information. File Name

Type the name of the file you want to import.


Add Constraint dialog box

Click to show or hide information. Constraint Type

Click the type of constraint you want to add to the selected predicate(s).

Notes

  • For Uniqueness constraints, select the Primary check box if you want this to be the basis for primary identifiers.
  • For Subset, Exclusion, or Equality constraints, if there is more than one role at each end of the constraint, increase the number in the Number of roles at each end to equal that number.
  • For Frequency constraints, under Minimum and Maximum, type the minimum and maximum number of times you want each object to play the role you specify.

Click to show or hide information. Select The Role Box Of Each Role In The Constraint

Click the roles in the selected predicate(s) that participate in the constraint.

Click to show or hide information. Reset

Click to clear all the settings in the dialog box so you can start over.

Note The constraint type defaults to Uniqueness whenever you click Reset.


New/Edit Ring Constraint dialog box

Click to show or hide information. Ring Constraint Value

Specifies the type of ring constraint you want to create.

Clicking the illustration also specifies the ring constraint type.

Click to show or hide information. Illustration

Specifies the type of ring constraint you want to create.

Choosing an option from the Ring Constraint Value list also specifies the ring constraint type.

Click to show or hide information. Verbalization

Describes the ring constraint.


ORM Document Options dialog box (General tab)

Click to show or hide information. Show Physical Constraints

Select to show index constraints in the list of constraints.

Click to show or hide information. Defaults

Click to change the default settings:

  • Set As Sets the new settings as the document default settings.
  • Restore Resets the document settings to the way the settings were when you first opened the dialog box.
  • Restore Original Resets the document settings to the original default settings.


About ORM source model options (Database Modeling)

You can set options that affect how an ORM source model

  • Maps to the collective logical model.
  • Displays physical constraints.

Click to show or hide information. Prefix and suffix options

You can select prefix and suffix options for columns and tables.

When you map a conceptual database model to a logical database model, the Visio program adds prefixes and suffixes to table and column names according to the current options.

For example, if you specify a table suffix of Tbl and a column prefix of the first four letters of the table name, mapping a conceptual database model to a logical database model creates table names such as CustomerTbl and EmployeeTbl, and column names such as CustFirstname and EmplFirstname.

Click to show or hide information. Capitalization rules

You can specify capitalization rules for

  • Column names.
  • Table names.
  • First letter of column and table names.

When you map a conceptual database model to a logical database model, these settings control the capitalization of automatically generated names.

Click to show or hide information. Name length and spacing

You can

  • Set the maximum length of table and column names.
  • Disallow spaces in names or replace spaces with a special character, such as an underscore.
  • Specify how to map a reference mode in an ORM model.

When you map a conceptual database model to a logical database model, these settings ensure that valid names are generated for your target database management system (DBMS) and your organization's naming conventions. For example, your DBMS may have limitations on table name size.

Click to show or hide information. Abbreviations

You can specify abbreviations for names you use in your conceptual database model.

When you map a conceptual database model to a logical database model, the abbreviations in the conceptual model are converted to their full names in the physical database.

Click to show or hide information. Physical constraints

You can specify whether to show or hide index constraints in the list of constraints.

This option has no effect when you map your ORM source model to a logical database model.

Notes

  • If you build a project's model before you set display options, you must rebuild the model for the settings to take effect.
  • If you change a name in the logical model, the ORM display options you set have no effect on the name when you rebuild the project.


Enter business rules (ORM)

  1. If the Business Rules window isn't already open, on the Database menu, point to View, and then click Business Rules.
  2. To add a new fact type, click the Fact Types tab, and then do one of the following to open the Fact Editor:
  • Press F2.
  • Start typing.
  • Double-click the last row of the Fact Types column.

The system analyzes the text you type in the Fact Editor to create object types, predicates, and constraints, which you can then drag onto the drawing page to create an ORM source model diagram.

  3. To add a new object type, click the Object Types tab, and then do one of the following:
  • Press F2.
  • Start typing.
  • Double-click the last row of the Object Types column.


Classify a new object in the Fact Editor (ORM)

  1. On the Database menu, point to View, and then click Fact Editor to open the Fact Editor.
  2. If you haven't already done so, enter a new fact on the Fact tab.
  3. Click the Object tab.
  4. In the Select object list, click the name of the object type you want to define.
  5. In the Object kind box, click the kind of object you are defining: Entity, Value, or External.
  6. If you clicked Entity, do the following:
  • In the Reference/identifier box, type the reference mode you want.
  • In the Ref type box, click the type of reference mode you want.
  7. Click OK.


Create a nested object type (ORM)

  1. On the Database menu, point to View, and then click Fact Editor to open the Fact Editor.
  2. If you haven't already done so, enter a new fact type on the Fact tab.
  3. Click the Advanced tab. In the Objectify/Nest fact as box, type the text that will become the name of the object type created by nesting the predicate of this fact type.
  4. Click OK.

The Fact Editor creates a new object type, but when you map your ORM source model to a logical model, Visio creates a column for each object type.


Add a derivation rule to a predicate definition in the Fact Editor (ORM)

  1. On the Database menu, point to View, and then click Fact Editor to open the Fact Editor.
  2. If you haven't already done so, enter a new fact type on the Fact tab.
  3. Click the Advanced tab, and then do one of the following:
  • Click Derived if you want to note the calculation but do not want to store the result in the database.
  • Click Derived and stored if you want to note the calculation and store the result in the database.
  4. In the Derivation rule box, type the derivation rule.

For example, you can enter a derivation rule in either of these formats:

Person1 is uncle of Person2 if Person1 is brother of a Person3 who is parent of Person2

Or,

define Person1 is uncle of Person2 as

Person1 is brother of a Person3 who is parent of Person2
  5. Click OK.


Change how the Fact Editor works by default (ORM)

  1. On the Database menu, point to Options, and then click Modeling.
  2. Click the Fact Editor tab.
  3. Do one or more of the following:
  • To specify a default style for entering facts, in the Category list, click Input Preferences. For Preferred mode, click Guided or Freeform. You can select further options for each input style.
  • To change the colors used when you enter a fact in freeform style, in the Category list, click Syntax Colors, and then select the color you want for each syntax element.
  • To set criteria for fact completeness and to set options for preferences regarding the general behavior of the Fact Editor, in the Category list, click Miscellaneous preferences, and then select the options you want.
  4. Click OK.


Create a fact type with an external object type and predicate (ORM)

  1. Open the ORM Source Model file that represents your model.
  2. Create and define a fact type.
  3. In another model, or on another page in the same model, create the same fact type.
  4. Define the new fact type's predicate and object type as external.


Delete a nested object type (ORM)

  1. On the Database menu, point to View, and then click Business Rules to open the Business Rules window.
  2. On the Object Types tab, click the nested object type you want to delete.
  3. Press DELETE.

Note You cannot delete a nested object type by selecting it on the drawing page and pressing DELETE.


ORM source model example

ORM diagram example.


Create an ORM source model from scratch

  1. On the File menu, point to New, point to Database, and then click ORM Source Model.
  2. On the Database menu, point to Options, and then click Document. In the ORM Document Options dialog box, choose options for your ORM model.
  3. Create facts by doing either of the following:
  • Connecting object types and predicates with role connectors
  • Defining facts in the Fact Editor
  4. Check for entity types that should be combined, and note any arithmetic derivations.
  5. Add uniqueness constraints, add mandatory constraints, and check for logical derivations.
  6. Add any value, set comparison, or subtyping constraints.
  7. Add other constraints.


Create an entity object type (ORM)

  1. Open the ORM Source Model file that represents your model.
  2. Double-click the object type shape that you want to define as an entity object type.
  3. In the Database Properties window, in the Categories list, click Definition.
  4. In the Kind box, choose Entity.


Create a value object type (ORM)

  1. Open the ORM Source Model file that represents your model.
  2. Double-click the object type shape that you want to define as a value object type.
  3. In the Database Properties window, in the Categories list, click Definition.
  4. In the Kind box, choose Value.


Change the verbalization of an object type (ORM)

  1. Open the ORM Source Model file that represents your model.
  2. Double-click the object type shape that you want to define as independent.
  3. In the Database Properties window, in the Categories list, click Definition. Select the Personal Pronoun check box to instruct the Verbalizer to use "his/her" in place of "its" in the verbalization.

The ORM source model is updated automatically.


Define an object type as external (ORM)

  1. Open the ORM Source Model file that represents your model.
  2. Double-click the object type that you want to define as external to open the Database Properties window.
  3. Define the object type so that it has the same name and properties as another object type in a different source model.
  4. In the Categories list, click Definition, and then select the External check box.

The ORM source model is updated automatically.


Define a reference mode for an entity object type (ORM)

  1. Open the ORM Source Model file that represents your model.
  2. Double-click the object type shape whose data type you want to define.
  3. In the Database Properties window, in the Categories list, click Ref Mode. In the Reference box, type the name of the reference scheme.
  4. From the Type list, choose the type of reference mode you want to define. Under Options, click the Reference Mode option you want to use.

The ORM source model is updated automatically.


Define an object type's data type (ORM)

  1. Open the ORM Source Model file that represents your model.
  2. Double-click the object type shape whose data type you want to define.
  3. In the Database Properties window, in the Categories list, click Data Type.
  4. Click Show portable data type, and then do one of the following:
  • In the User defined list, select a user-defined data type that you have created.

Click to show or hide information. Tip

To create a user-defined data type, on the Database menu, click User Defined Types, and then click Add.

  • Define a portable data type by selecting or entering the data type settings you want.

The ORM source model is updated automatically.


Create a subtype-supertype relationship (ORM)

  1. Open the ORM Source Model file that represents your model.
  2. Create the entity object types that will be related as subtype and supertype (for example, Woman and Person).
  3. From the ORM Source stencil, drag the Subtype Relationship shape onto the drawing page.
  4. Drag the plain end [image] of the subtype relationship to the object type shape that represents the subtype. When the connector end is outlined, release the mouse button.
  5. Drag the arrow end [image] of the subtype relationship to the object type shape in the diagram that represents the supertype. When the connector end is outlined, release the mouse button.
  6. Double-click the subtype whose properties you want to define.
  7. In the Database Properties window, in the Categories list, click Definition. In the Name box, type the name of the subtype.
  8. In the Categories list, click Subtype, and then do one of the following:
  • If you want the subtype to map to its own table when the logical model is built, select the Map to separate table check box. If you want the subtype to have a different primary identification scheme than its supertype, click Ref Mode and enter a reference mode, and then click Data Type and enter data type characteristics.

Note do not give the subtype a different primary identifier unless it is absolutely necessary.

  • If you do not want the subtype to map to its own table when the logical model is built, clear the Map to separate table check box, leave the Ref Mode section blank, and do not enter any data type information in the Data Type section.

The ORM source model is updated automatically.


Connect a subtype to a supertype (ORM)

  1. From the ORM Source stencil, drag the Subtype Relationship shape onto the drawing page.
  2. Drag the plain end [image] of the subtype relationship to the object type shape that represents the subtype. When the connector end is outlined, release the mouse button.
  3. Drag the arrow end [image] of the subtype relationship to the object type shape in the diagram that represents the supertype. When the connector end is outlined, release the mouse button.


Set the primary supertype of a subtype (ORM)

  1. Double-click the subtype whose primary supertype property you want to define.
  2. In the Database Properties window, in the Categories list, click Subtype. In the Primary supertype list, choose the name of the primary supertype.

The ORM source model is updated automatically.

Note If a subtype has more than one direct supertype, you can use these steps to choose which supertype is used as the primary parent when the subtype is mapped to a logical database model. By default, the subtype inherits the primary identification scheme of its primary supertype, and its functional fact types are grouped into the same table as that of its primary supertype.


Limit the possible values for an object type (ORM)

  1. Open the ORM Source Model file that represents your model.
  2. Double-click the object type whose value you want to limit. In the Database Properties window, in the Categories list, click Value.
  3. Type the range, value, or set of ranges and values that define the constraint you want, as follows:
  • To create a range of values, type the minimum value in the From box, type the maximum value in the To box, and then click Add. The limits you enter are included in the range.
  • To create a list of values, type a value in the Value box, and then click Add. Repeat this step for each value you want to include in the value constraint. Do NOT add quotes around the values you enter. Visio uses the data type declared for the object type to determine whether quotes are needed.

The ORM source model is updated automatically.

Notes

  • If the object type appears on the drawing page, the list of possible values appears in braces next to the object type. You can move this list by clicking the object type and dragging the control handle ( [image]).
  • By default, up to five values are displayed. To change this default, right-click the object type, point to Shape, click Custom Properties, and type the desired number for Value list size.


Delete a value constraint for an object type (ORM)

  1. Open the ORM Source Model file that represents your model.
  2. Double-click the object type whose value constraint you want to delete. In the Database Properties window, in the Categories list, click Value.
  3. Select the value constraint you want to delete in the Defined values/ranges list, and then click Remove.

The ORM source model is updated automatically.


Define a name space for an object type (ORM)

  1. Open the ORM Source Model file that represents your model.
  2. Double-click the object type whose name space you want to define.
  3. In the Database Properties window, in the Categories list, click Definition. Type the text in the Name Space box.

The ORM source model is updated automatically.


Move an object type to a new page or to another model (ORM)

  1. Select the object type you want to move in the first model document.
  2. On the Edit menu, click Cut.
  3. Open or switch to the second model document, and then navigate to the page where you want the object type to appear.
  4. On the Edit menu, click Paste.


Create an independent object type (ORM)

  1. Open the ORM Source Model file that represents your model.
  2. Double-click the object type shape that you want to define as independent.
  3. In the Database Properties window, in the Categories list, click Definition and then select the Independent check box.

The ORM source model is updated automatically.


About enhanced object types

You can define enhanced object types, such as subtypes, supertypes, nested object types, independent entities, and composite object types.

Subtypes and supertypes

Click to show or hide information. Subtypes and supertypes

A supertype is an entity object type to which one or more subtypes are connected.

A subtype is an entity object type whose population represents a portion of the population of a supertype.

To symbolize a supertype and subtype relationship, draw the supertype, draw the subtype, and then use the Subtype Relationship shape to connect them. After you create and connect the subtype and supertype, you can define options for the subtype.

Click to show or hide information. Subtypes and supertypes illustrated

In the example below, Supervisor, Clerk, and Technician are distinct entity types because they play different roles. However, they also participate in some identical roles, such as having names, addresses, and similar personal data, which are represented by using subtypes.

Subtype and supertype examples.

The entity object types Supervisor, Clerk, and Technician are subtypes of the supertype, Employee.

Click to show or hide information. Multiple inheritance

ORM supports multiple inheritance for subtypes. A subtype has multiple inheritance when it has more than one direct supertype.

In most cases, you do not need to take special steps to define a supertype. However, when a subtype has more than one supertype, you must define the primary supertype for that subtype.

Multiple inheritance example.

Multiple inheritance for a subtype (Student Employee) that has more than one supertype.

Other enhanced object types

Click to show or hide information. Nested object types (objectified association)

An objectified association is formed when an association is objectified as an object type. For example, "Person enrolled in Course" might be objectified as "Enrollment." An objectified association is also known as a nested object type. Once you define an objectified association, you can assign roles to it.

Click to show or hide information. Independent entities

An independent entity object type is drawn in an ORM source model diagram as an entity object type with an exclamation point (!) after its name. An independent entity object type is intended to be a lookup table. Instances of an independent object type may exist without playing in any fact types.

Click to show or hide information. Co-referenced object types

A co-referenced object type is identified by a combination of two or more reference types. A co-referenced object type is indicated by an external uniqueness constraint. For example, a Room might be referenced by combining its Building with its local RoomNumber.


Create a co-referenced object type (ORM)

  1. Select the predicates to which you want to add an external uniqueness constraint.
  2. Right click one of the predicates, and then click Add Constraints.
  3. In the Constraint type list, click Uniqueness. Select the role box of each role in the constraint, and then click OK.

Click to show or hide information. Tip

Click Reset to clear your role box selections.

  4. If you want the external uniqueness constraint to provide the primary identification scheme for the object type, select the Primary check box.
  5. Click OK.


Define a predicate as external (ORM)

  1. Open the ORM Source Model file that represents your model.
  2. Double-click the predicate that you want to define as external to open the Database Properties window.
  3. Define the predicate so that it has the same name and properties as another predicate in a different source model.
  4. Check External.

The ORM source model is updated automatically.


Connect a role to a different object type (ORM)

  1. Open the ORM Source Model file that represents your model.
  2. Select the role connector in the diagram that you want to reroute.
  3. Drag the end point away from the Object Type shape, and then glue it to another Object Type shape.


Define a name space for a predicate (ORM)

  1. Open the ORM Source Model file that represents your model.
  2. Double-click the predicate to which you want to add a name space, and then, in the Database Properties window, in the Categories list, click Definition.
  3. Type the distinguishing text in the Name Space box.

The ORM source model is updated automatically.


Apply uniqueness constraints to a predicate automatically (ORM)

  1. Open the ORM Source Model file that represents your model.
  2. Double-click the predicate to which you want to apply uniqueness constraints automatically, and then, in the Database Properties window, in the Categories list, click Examples.
  3. Type the example data, if you have not already done so.
  4. Click Set UC Constraints.

The ORM source model is updated automatically.

Note If any errors are found, the uniqueness constraints are not applied, and the Example Analysis dialog box opens to show you the errors.


Create a derivation rule (ORM)

  1. Open the ORM Source Model file that represents your model.
  2. Double-click the predicate to which you want to add a derivation rule, and then, in the Database Properties window, in the Categories list, click Derived.
  3. Click the type of derivation rule you want to use: None, Derived, or Derived and stored.
  4. In the Rule box, type the derivation rule.

The ORM source model is updated automatically.


Move a predicate from one page to another (ORM)

  1. Open the ORM Source Model file that represents your model.
  2. Select the predicate.
  3. On the Edit menu, click Cut.
  4. Navigate to the page where you want the predicate to appear.
  5. On the Edit menu, click Paste.

Note Only the predicate will be moved to the new page. Any object types to which the predicate was connected remain on the original page.


About derivation rules

Some facts can be derived from mathematical calculations or logical inferences (referred to as derivation rules) that involve other facts in the model.

You can create two types of derivation rules:

  • Derived Use when you want to add the derivation rule to the conceptual model but do not want its associated fact stored in the physical database.
  • Derived and Stored Use when you want to add the derivation rule to the conceptual model and store the derived fact in a base table of the physical database.

A common derivation rule is one that calculates a sum.

A derivation rule is treated as an informal comment, so you can enter it in any way you prefer. The following ways are all acceptable:

Total income equals earned income plus other income

Total income = earned income + other income

Define Person1 is uncle of Person 2 as

Person 1 is brother of a Person3 who is parent of Person2

Create a derivation rule